kyoto root # emerge games-mud/crystal Calculating dependencies ...done! >>> emerge (1 of 1) games-mud/crystal-0.2.1 to / >>> md5 src_uri ;-) crystal-0.2.1.tar.gz creating temp dir ACCESS DENIED open_wr: /etc/passwd.13880 usermod: unable to lock password file sandbox exists- /tmp/sandbox-22311.log --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-22311.log" open_wr: /etc/passwd.13880 -------------------------------------------------------------------------------- SANDBOX_ON:=1 SANDBOX_DISABLED:=0 SANDBOX_READ:=/:/dev/shm:/var/tmp SANDBOX_WRITE:=/dev/zero:/dev/fd/:/dev/null:/dev/pts/:/dev/vc/:/dev/tty:/tmp/:/dev/shm/ngpt:/var/log/scrollkeeper.log:/usr/tmp/conftest:/usr/lib/conftest:/usr/lib32/conftest:/usr/lib64/conftest:/usr/tmp/cf:/usr/lib/cf:/usr/lib32/cf:/usr/lib64/cf:/tmp/.gconfd/lock:/tmp/.bash_history::/tmp:/var/tmp:/tmp/:/var/tmp/:/tmp/sandbox-22311.log:/dev/shm:/var/tmp:/tmp/sandbox-22311.log:/var/log/portage/2184-crystal-0.2.1.log SANDBOX_PREDICT:=/tmp/.:/usr/lib/python2.0/:/usr/lib/python2.1/:/usr/lib/python2.2/:/usr/lib/python2.3/:/usr/lib/python2.4/:/usr/lib/python2.5/:/usr/lib/python3.0/::/proc/self/maps:/dev/console:/usr/lib/portage/pym:/dev/random SANDBOX_DEBUG:=1 SANDBOX_DEBUG_LOG:=/tmp/sandbox-debug-.log SANDBOX_LOG:=/tmp/sandbox-22311.log SANDBOX_ARMED:=unset phases failed This only happens if games in /etc/passwd has /bin/false as the shell. from IRC in portage-dev: antarus|x86 for the usermod, where in the ebuild is it legal to go? src_install()? spb preinst/postinst I'll test it out and make sure it works there.
Created attachment 52694 [details, diff] Moves usermod to games_post_inst(), suggests moving other code right now pre and post inst run with full privs ( to merge to live filesystem ). I left the other enewuser things for you to move; I can't really envision a situation where they wouldn't exist...but still nice to have them there.
what about this diff: --- games.eclass 18 Feb 2005 21:55:35 -0000 1.89 +++ games.eclass 9 Mar 2005 02:20:30 -0000 @@ -142,7 +142,7 @@ # Dear carpaski and portage-dev team, we are so sorry. Lots of love, games team # See Bug #61680 [[ $(getent passwd "${GAMES_USER_DED}" | cut -f7 -d:) == "/bin/false" ]] \ - && usermod -s /bin/bash "${GAMES_USER_DED}" + && env SANDBOX_ON="0" usermod -s /bin/bash "${GAMES_USER_DED}" } games_src_compile() {
The whole point is that src_compile is designed to run with reduced privs. That will in fact work for now; however it will most probably break in future revisions of portage as privs are stripped out ( SELINUX comes to mind ). I know spb was talking about reducing privs of sections via SElinux policy in which case even with SANDBOX disabled that code will fail. I don't see the issue moving the usermod stuff to preinst() as a big deal...Any reason why this can't be done? Your diff seems more like a hack aroundn the issue...
wtf does src_compile() have to do with this ? our usermod functions run in pkg_setup() which require running as root and really should not have sandbox turned on (imho), but that's a different story
Sorry, I did mean pkg_setup(). IIRC the only 2 functions not sandbox'd (besides the actual merge to the filesystem ) are pre_inst() and post_inst(). That is why I suggested putting them there. However I do not think there is confirmed policy on which functions will have which permissions in the future. Because of that I'm not going to really push moving it somewhere else. [update] After chatting a bit in #-portage pkg_setup() supposidly shouldn't have sandbox enabled. Let me file a bug against portage to make sure, if so this one is invalid.
see 84960 filed against portage HEAD
Portage HEAD issue
