ACCT_USER_HOME_PERMS and ACCT_USER_HOME_OWNER should control the owner and the permission bits of the users homedir. But they only really work for the first time the package gets installed. Or for the first install of one of several packages, i.e. acct-user/mail and acct-user/postmaster share /var/spool/mail If a directory already pre-existed before merge, neither perms nor owner will ever be updated. I found this when debugging local mail delivery problems on two rather old gentoo installations, even predating acct-user. What acct-user/mail should have set was rather off. Steps to repro (best do this in docker or remember to undo): 1. check your current perms/owner on /var/spool/mail (assuming acct-user/mail is installed already) ls /var/spool/mail/ -al > drwxrwsr-t 2 root mail 4096 Jun 22 17:29 . if it differs you already reproduced and likely used an older system 2. mess it up a bit chmod o-rtx /var/spool/mail chown mail:mail /var/spool/mail/ ls /var/spool/mail/ -al > drwxr-s--- 1 mail mail 4096 Jun 22 17:29 . 3. repair it emerge acct-user/mail ls /var/spool/mail/ -al drwxr-s--- 1 root mail 4096 Jun 22 17:29 . 4. finally really repair it in case you care about that system you used chmod 03755 /var/spool/mail chown root:mail /var/spool/mail Expected result would be that "emerge acct-user/mail" would control via ACCT_USER_HOME_OWNER and ACCT_USER_HOME_PERMS and therefore repair the damage done in step 2. The actual result is that nothing happens and ACCT_USER_HOME_OWNER/_PERMS have no effect on a reinstall or upgrade. This is bad because permission bits can never be updated using these two variables, which smell like security for sure. And updates are necessary over time.
https://github.com/gentoo/portage/pull/1381
Here is one example where a shared dir and merge order have been a problem before https://bugs.gentoo.org/913346
And here are two examples of commits which likely never worked as intended when the package was previously installed. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6a14a63cd8f5ce5e44aa5b10ada1fa99ff317329 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a356dc6c6272ec93eca5c34e008d12fe2f9a7475
This is a general issue with any directory installed by Portage: the permissions are only set by the initial merge. acct-user isn't really special here.
The general issue is known and it for sure is also a feature and not just an issue. However the two variables even existing strongly suggest that owner/perm manipulation is possible. In my PR i suggested a patch which likely goes way too far. But maybe an "ewarn" in postinst could do the trick in the end. Or some sort of dispatch-fperms tool, where users decide which local changes to keep and which upstream changes to apply.
Gotcha, I'm just catching up on the backstory here and all the linked bugs. I added a PR to work around the issue for acct-user.eclass.
