Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 42320 - using ROOT env variable with eutils.eclass enewuser incorrectly adds user to wrong password file
Summary: using ROOT env variable with eutils.eclass enewuser incorrectly adds user to ...
Status: RESOLVED DUPLICATE of bug 53269
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: SpanKY
: 96988 116193 159517 389159 (view as bug list)
Depends on:
Reported: 2004-02-20 18:15 UTC by Daniel Black (RETIRED)
Modified: 2011-11-21 16:14 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Black (RETIRED) gentoo-dev 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 gentoo-dev 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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 2004-12-29 18:22:41 UTC
goes glep 27 address this?
Comment 5 SpanKY gentoo-dev 2004-12-29 18:31:48 UTC
yes, see Bug 53269
Comment 6 SpanKY gentoo-dev 2005-03-20 21:28:48 UTC

*** This bug has been marked as a duplicate of 53269 ***
Comment 7 SpanKY gentoo-dev 2005-06-24 18:20:11 UTC
*** Bug 96988 has been marked as a duplicate of this bug. ***
Comment 8 Yuri Vasilevski (RETIRED) gentoo-dev 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) gentoo-dev 2005-12-20 11:08:17 UTC
*** Bug 116193 has been marked as a duplicate of this bug. ***
Comment 10 Jakub Moc (RETIRED) gentoo-dev 2006-12-30 15:50:42 UTC
*** Bug 159517 has been marked as a duplicate of this bug. ***
Comment 11 SpanKY gentoo-dev 2011-11-01 17:18:44 UTC
*** Bug 389159 has been marked as a duplicate of this bug. ***