On 2019-03-24 6:02 p.m., Viktor Dukhovni wrote: >> On Mar 24, 2019, at 4:33 PM, Simon Deziel <si...@sdeziel.info> wrote: >> >> I am running postfix (3.3.0-1ubuntu0.2) confined by Apparmor and I >> noticed the tlsproxy process is apparently trying to connect to tlsmgr's >> Unix socket while still running as root. > > The premise is false. On all the systems I've used, the "private" directory > belongs to the "$mail_owner" user: > > $ ls -ld /var/spool/postfix/private/ > drwx------ 2 postfix wheel 24 Mar 3 02:49 /var/spool/postfix/private/
Sorry, I should have included that as it look the same here: $ ls -ld /var/spool/postfix/private/ drwx------ 2 postfix root 4096 Mar 24 16:54 /var/spool/postfix/private/ > and connections to peer services (e.g. to tlsmgr(8)) often happen after privs > are dropped. Agreed, but I'm not concerned about the after. > Some requests may happen before that, but the directory must be > generally readable by $mail_owner. I was not clear because my issue is indeed with those accesses before privs get dropped. I noticed that tlsproxy accesses tlsmgr's socket while still running as root so it depends on its CAP_DAC_READ_SEARCH capability. My workaround to not need that cap was to change the perms to be like: $ ls -ld /var/spool/postfix/private/ drwx--x--- 2 postfix root 4096 Mar 24 16:54 /var/spool/postfix/private/ And with that group search bit on, the tlsproxy process no longer depends on the CAP_DAC_READ_SEARCH cap to get to tlsmgr's socket. In other words, this group search bit allows to _not_ depend on the CAP_DAC_READ_SEARCH which sounded like an improvement to me. That's what I wanted to validate with the mailing list. Thanks, Simon
