A user reported that acct-group/portage was adding the group to their host's /etc/group. This is unexpected behaviour. Right now, we check if we're root and bail out if not which covers most Prefix cases. While we don't (as far as I know) officially support Prefix-as-root, this is an extremely cheap change to make to avoid breakage, especially if this is one of the only issues people are actually hitting in production. We should check for EPREFIX != / (or some other check if more suitable).
It should also work to pass --prefix $EPREFIX to groupadd and so. All of that should be possible to do in user.eclass.
I checked and it appears to work -- passing --prefix to groupadd and useradd if shadow is installed.
> This is unexpected behaviour. Is it really unexpected? How should user/group management on prefix work? How can we ensure that the necessary users/groups are available for installed software to use? I would guess that adding entries to ${EPREFIX}/etc/{passwd,group} would probably not be very useful.
I would also like to know what is unexpected. If you are running as root, you are basically asking PREFIX to create these users. The user running prefix is the only indicator we have. Keep in mind that we have multiple PREFIX variants. Some of them should only install into an offset (i.e. to allow to make use of packages from Gentoo repository) but you still want the users. I only see an inconsistency: Sometimes we check for EUID and sometimes we check for USE=prefix to decide if we want to pull in users...
(In reply to Mike Gilbert from comment #3) > > This is unexpected behaviour. > > Is it really unexpected? How should user/group management on prefix work? > How can we ensure that the necessary users/groups are available for > installed software to use? Simply put, it doesn't. That's hotw it's always worked. > > I would guess that adding entries to ${EPREFIX}/etc/{passwd,group} would > probably not be very useful. Yep. (In reply to Thomas Deutschmann from comment #4) > I would also like to know what is unexpected. > > If you are running as root, you are basically asking PREFIX to create these > users. The user running prefix is the only indicator we have. Keep in mind > that we have multiple PREFIX variants. Some of them should only install into > an offset (i.e. to allow to make use of packages from Gentoo repository) but > you still want the users. Doing anything outside of the EPREFIX is a no-no which is the problem. We do not support this case (running as root) really _anyway_, this is just a simple workaround/fix to ensure consistent behaviour, which leads me to... > > I only see an inconsistency: Sometimes we check for EUID and sometimes we > check for USE=prefix to decide if we want to pull in users... Exactly.
I mean, ignoring this being unexpected, it's broken. Software looks at the database in $EPREFIX/etc/{group,passwd,shadow}. groupadd / useradd adds the user to /etc/{group,passwd,shadow}. It should be caused with the --prefix or --chroot option to fix this.
It seems odd that software would look at EPREFIX/etc/passed. That means you would have 2 disparate user databases with names and ids that might conflict. I suspect this also depends on whether you link the prefix software against the system libc, or a prefixed libc. Either is probably feasible.
Instead of assuming that all prefix users want to disable this, maybe we should define a new eclass var to disable the update functionality of user.eclass. Users could set this in make.conf and it could be set in prefix profiles if desired.
(In reply to Sargun Dhillon from comment #6) > I mean, ignoring this being unexpected, it's broken. Software looks at the > database in $EPREFIX/etc/{group,passwd,shadow}. groupadd / useradd adds the > user to /etc/{group,passwd,shadow}. It should be caused with the --prefix or > --chroot option to fix this. I wonder if this is actually fixed by bug 541406. I guess not if something is running it within prefix as ROOT will still be empty.
(In reply to Mike Gilbert from comment #7) > It seems odd that software would look at EPREFIX/etc/passed. That means you > would have 2 disparate user databases with names and ids that might > conflict. > > I suspect this also depends on whether you link the prefix software against > the system libc, or a prefixed libc. Either is probably feasible. Based on this, I'm unsure about whether --prefix on groupadd and friends in user*.eclass makes sense. I suppose, again, it kind of does if you're doing things as root, even though it's odd. so I guess let's: 1. bail out if EPREFIX is non-empty, unless.. 2. some USER_ECLASS_ALLOW_ROOT_PREFIX=yes is set by the user?
I've dealt with this in https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=eabd386679e85e14532642e4fd03585acb6e881a by bailing out if EPREFIX is non-empty. Feel free to take this further if you want.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cfad8158b77d70f92698d1d616f778cd8d4656b1 commit cfad8158b77d70f92698d1d616f778cd8d4656b1 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2022-12-08 09:16:41 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2022-12-27 23:48:47 +0000 acct-group.eclass: Don't modify groups when EPREFIX is non-empty This was happening when running a prefix as root, which we don't really support, but also when building a prefixed system under ROOT. Closes: https://bugs.gentoo.org/779181 Signed-off-by: James Le Cuirot <chewi@gentoo.org> eclass/acct-group.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
I'd pushed the users commit but not the groups commit. Woops!
