Re: [PATCH 1/6] acct-user.eclass: Automatically add deps based on ACCT_USER_HOME_OWNER

On Tue, Jun 23, 2026 at 10:00:53AM -0400, Michael Orlitzky wrote:
> On 2026-06-23 11:43:04, James Le Cuirot wrote:
> > Some acct-user packages were manually adding these dependencies but most
> > were not, sometimes causing failures at installation time.
> 
> Setting ACCT_USER_HOME_OWNER is almost always a mistake. The package
> manager doesn't manage directories, so it's possible for two different
> packages to "claim" the same directory, and obviously not great if two
> different packages fight over the ownership of and permissions on an
> important directory.
> 
> Choosing a random example (sorry whoever maintains this, I didn't look),
> 
>   $ grep -C 2 ACCT_USER_HOME_OWNER unbound/unbound-0-r3.ebuild
>   ACCT_USER_ID=391
>   ACCT_USER_HOME="/etc/${PN}"
>   ACCT_USER_HOME_OWNER="root:${PN}"
>   ACCT_USER_HOME_PERMS=0750
>   ACCT_USER_GROUPS=( ${PN} )
> 
> This is a mistake because ownership and permissions on /etc/unbound
> should be set in the ebuild... in fact, the ebuild already does this:
> 
>   # Create space for auto-trust-anchor-file eventually
>   # downloaded by unbound-anchor
>   keepdir /etc/unbound/var
>   fowners root:unbound /etc/unbound/var
>   fperms 0770 /etc/unbound/var
> 
> But now we have two packages fighting over the permissions on
> /etc/unbound. If one of them gets out of sync we can wind up with a
> security issue.
> 
> tl;dr if the package needs special permissions and ownership on any
> directories, the ebuild should do that, and the acct-user package
> should use some other directory entirely to avoid chmod/chown clashes.
> 
> About half of the examples in the tree are of the type above. Some
> others look sketchy, like acct-user/{nobody,sshd} both setting
> ownership and permissions on /var/empty. The legitimate cases probably
> fit on one hand.

You seem to be saying that ACCT_USER_HOME_OWNER shouldn't go away entirely, and
therefore the fix still makes sense? I think your argument makes sense, but I'd
never heard of ACCT_USER_HOME_OWNER before I hit this issue, so I think someone
else should decide what to do.