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

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.