Re: Best practice to allow a program to write its logs

[l0f4r0@tuta.io]

Hi,

Oops, I didn't answer to that, sorry...

23 févr. 2020 à 21:08 de recoverym4n@enotuniq.net:

> On Sun, Feb 23, 2020 at 08:31:59PM +0100, l0f4r0@tuta.io wrote:
>
>> 23 févr. 2020 à 18:02 de recoverym4n@enotuniq.net:
>>
>> > Clever, but not any filesystem supports ACL.
>> > And you would have created a problem by your own hands if you're doing
>> > backups (depends on a type of a backup, of course).
>> >
>> Interesting... but I'm using ext4 everywhere so it's OK ^^
>>
> It all works - conventional POSIX permissions, ACLs, xattrs, SELinux
> Labels, etc. Until you try to restore from a backup :)
>
What do you mean please? Why does the backup would pose a problem when restored?

>> > A conventional way is simple - do not deviate from distribution
>> > defaults (in this case - logging to a package-assigned file).
>> > In this case such approach solves numerous issues with log rotating, log
>> > gathering, log analyzing etc.
>> >
>> > Of course, there are cases of legitimate needs to deviate from
>> > distribution defaults. I'd like to hear yours.
>> >
>> You mean for this use case writing into /var/log/msmtp?
>> Actually, I don't really know why but I've decided to write user
>> specific configuration with appropriate logs.  So my conf is not in
>> /etc/msmtprc but in ~/.msmtprc and logging is in the same vein inside
>> ~/.msmtp.log.
>>
>
> My advice to you then - don't do this.
> Best are not the logs that are written often or are verbose, and even
> not those are written in a convenient filesystem locations.
> Best are the logs which contain the problem, but do not contain assorted
> junk (implies logs filtering), 
>
How to you filter your logs? Directly by tweaking severities in (r)syslog(-ng).conf?

> are small (implies periodic rotation)
>
logrotate I presume?
> and, the most importantly, are stored not only on your host, but
> elsewhere, preferrably in a centralized and indexed way.
>
Via (r)syslog(-ng)?

>> Anyway, even if I choose /var/log/msmtp, this directory/file needs to
>> be created so I have the same problematic (except l0f4r0 is not the
>> owner/group of /var/log, but root is), right?
>>
>
> A false dichotomy. Why reinventing a wheel with custom logging if they
> given you that "--syslog=on" option?
>
I didn't notice that, thanks! :)
So you recommend not specifying any logfile in /etc/msmtprc but just use switch "--syslog=on" everytime msmtp is used? Maybe this can be viewed as a constraint as one should remember to use that option... (except by using some trick as an alias)

>> >> how can I know for sure which service/technical account is used for
>> >> writing msmtp logs?
>> >>
>> >
>> > Try executing "ps -ef | grep msmtp".
>> >
>> Nothing. This would work for commands taking long time to be processed I think, not quick/almost instantaneous ones...
>>
>
> Ah, that's not a real MTA. My mistake.
> A quick look at postinst script gives me:
>
> chgrp msmtp /usr/bin/msmtp
> chmod 2755 /usr/bin/msmtp
>
In a nutshell, an application triggers actions under the identity of who launched it initially, except if the application makes use of a specific technical account, right?
If so what is the best way to know if an application operates under a specific account?
I had the instinct to verify /etc/passwd while, if I'm correct, you suggested "ps -ef" and checked msmtp.postinst inside msmtp source deb file... Do you see another way?

> Assuming a typical permissions for the Debian-packaged binary (which are
> 755, uid:gid = 0:0), it gives us:
>
> The resulting permissions of 2755, owner root, group msmtp.
>
> So, every time a user invokes msmtp, the resulting process owner does
> not change (same as user's), primary group changes to msmtp even if a
> user does not has it.
>
Yes, setgid here...

Thank you! :)
Best regards,
l0f4r0