Hi, Oops, I didn't answer to that, sorry...
23 févr. 2020 à 21:08 de recovery...@enotuniq.net: > On Sun, Feb 23, 2020 at 08:31:59PM +0100, l0f...@tuta.io wrote: > >> 23 févr. 2020 à 18:02 de recovery...@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
