Bug 42320 – using ROOT env variable with eutils.eclass enewuser incorrectly adds user to wrong password file

• Product: Gentoo Linux
• Status: RESOLVED DUPLICATE

[Description Daniel Black (RETIRED) 2004-02-20 18:15:04 UTC]

using "env ROOT=/path/to/ends/of/earth emerge ...."
on an ebuild that uses enewuser will cause the user to be added to the /etc/password file rather than the $ROOT/etc/password file.

Likewise with enewgroup.

Suggest a chroot in a vain attempt to eliminate some of the troubles.

If I get time I will post a fix for eutils.eclass however I'm a bit swampped at the moment (as I'm sure you are too). I just felt obliged to report this for now.

[Comment 1 SpanKY 2004-02-27 12:51:12 UTC]

ok, theres a problem with this ... i can implement a hack, but that's as good as it's gonna get ...

enew{user,group} was written so that we wouldnt have to worry about what kind of auth schema the user had ... they could use classic /etc/{passwd,group} or they could use ldap (in which case, it couldnt matter if they even had /etc/{passwd,group} files)

the other issue is that if we only add the users to ${ROOT}, if the ebuild tries to `chown` or `chgrp` a file, things are going to be screwed up because the `chown` and `chgrp` will only know about users/groups on the host system, not the ${ROOT} system, thus possibly leaving the ${ROOT} system fubar

here's the solution (and thus the hack) that i can implement ... i wont implement it right away that way you guys can give me feedback on it ...
(1) add the user/group to the host system
(2a) if ${ROOT}/`which useradd` exists, we just `chroot ${ROOT}` before executing the adduser command
(2b) if ${ROOT}/`which useradd` doesnt exist, we just cry and add entries by hand to ${ROOT}/etc/{passwd,group} with good old `echo "user record" >> ${ROOT}/etc/passwd`

[Comment 2 Daniel Black (RETIRED) 2004-03-02 14:53:51 UTC]

fine with 2a & 2b.

Alternate thoughts to 1:
1a Place getgrnam getpwnam getpwuid getgrgid functions into the sandbox (obtained from ch{own,grp} source). Call chroot(2) before passing args back on to the calling the original functions.
1b make an alternate ch{own,grp} that conforms to the $ROOT in the path - will have problems make using direct calls to the OS.

Alternate to 2 is:
sandbox pw_open, spw_open, gr_open, sgr_open simarly to 1a.

[Comment 3 Daniel Black (RETIRED) 2004-03-02 16:07:40 UTC]

ignore  pw_open, spw_open, gr_open, sgr_open they are internal shadow functions.

Alternately intercept open("/etc/{passwd,shadow,group}") function calls. I'm implementing this now as a test.

[Comment 4 Daniel Black (RETIRED) 2004-12-29 18:22:41 UTC]

goes glep 27 address this?

[Comment 5 SpanKY 2004-12-29 18:31:48 UTC]

yes, see Bug 53269

[Comment 6 SpanKY 2005-03-20 21:28:48 UTC]

*** This bug has been marked as a duplicate of 53269 ***

[Comment 7 SpanKY 2005-06-24 18:20:11 UTC]

*** Bug 96988 has been marked as a duplicate of this bug. ***

[Comment 8 Yuri Vasilevski (RETIRED) 2005-10-13 10:33:33 UTC]

Will it be possible (as in "good idea") until GLEP 27 gets implemented to add a
notice of the sort:
* You'll need to manually add a user/group in ROOT=${ROOT} with:
*   name: ____
*   uid/gid: ___ (if any)
*   shell: ____
*   home: ____ $(test -d $home || echo "(this needs to be created)")

Or something like this?

[Comment 9 Jakub Moc (RETIRED) 2005-12-20 11:08:17 UTC]

*** Bug 116193 has been marked as a duplicate of this bug. ***

[Comment 10 Jakub Moc (RETIRED) 2006-12-30 15:50:42 UTC]

*** Bug 159517 has been marked as a duplicate of this bug. ***

[Comment 11 SpanKY 2011-11-01 17:18:44 UTC]

*** Bug 389159 has been marked as a duplicate of this bug. ***