Re: Best practice to allow a program to write its logs
Hi.
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 :)
> > 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), are small (implies periodic rotation)
and, the most importantly, are stored not only on your host, but
elsewhere, preferrably in a centralized and indexed way.
> 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?
If syslog is not convenient to you - run mstmp as a systemd service and
just dump the log to stdout. journald will take care of it.
Of course, that way it won't be filtered, it will have problems with the
rotation and the less said about journald remote logging - the better.
But systemd is a Debian default, so you might as well use the facilities
that are provided by it.
> >> _NB_: by the way, does anybody have a tip to know what user account is
> >> used during a specific command please? For example when using
> >> echo -e "Subject: mySubject\nThis is myBody" | msmtp my_email_address
> >>
> >
> > Something like this should do it:
> >
> > cat << EOF | msmtp my_email_address
> > From: myFrom <fakeuser@fakedomain.tld>
> > Subject: mySubject
> >
> > This is myBody
> > EOF
> >
> > It won't fool an MTA, of course (you won't override Envelope-From *that*
> > easy), but it will show up nicely in your e-mail client.
> >
> I did that, it works on Gmail ("myFrom" is displayed but
> "fakeuser@fakedomain.tld" is
> <mailto:fakeuser@fakedomain.tldis> replaced with "from" value in
> ~/.msmtprc).
> Why do you suggest this to me? What's your point here please? ;)
Ah, that. Your effective uid is fed to getpwent(3) or equivalent
(/etc/passwd in layman's terms), your "outgoing" e-mail (Envelope-From
in this speak) is likely to be <your_current_username>@<fqdn>.
Too lazy to install msmtp to check it out or dig into the source, sorry.
Nullmailer and exim cover my needs in that regard.
> > If you need to do it for real - consider using "mail" from "bsd-mailx"
> > package.
> >
> Why? More flexible?
If you really need a full control over e-mail headers - yes.
> >> 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
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.
It should be possible to override this by dpkg-statoverride for whatever
reason, but then again - there are defaults, it's unwise to deviate from
them.
Reco
Reply to: