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.
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`
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.
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.
goes glep 27 address this?
yes, see Bug 53269
*** This bug has been marked as a duplicate of 53269 ***
*** Bug 96988 has been marked as a duplicate of this bug. ***
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?
*** Bug 116193 has been marked as a duplicate of this bug. ***
*** Bug 159517 has been marked as a duplicate of this bug. ***
*** Bug 389159 has been marked as a duplicate of this bug. ***
