I use a grsecurity kernel with the TPE (trusted path execution) feature turned on and FEATURES='userpriv' # emerge db [..] >>> Source unpacked. * Configuring db-3.2.9 (static)... /usr/sbin/ebuild.sh: ../dist/configure: /bin/sh: bad interpreter: Permission den ied !!! ERROR: sys-libs/db-3.2.9-r7 failed. !!! Function src_compile, Line 80, Exitcode 126 !!! (no error message) peter db-3.2.9-r7 # tail -1 /var/log/everything/current Aug 22 15:54:59 [kernel] grsec: denied untrusted exec of /var/public/tmp/portage/db-3.2.9-r7/work/db-3.2.9/dist/configure by (ebuild.sh:6859) UID(250) EUID(250), parent (ebuild.sh:4500) UID(250) EUID(250) peter root # stat /var/public/tmp/portage/db-3.2.9-r7/work/db-3.2.9/dist File: `/var/public/tmp/portage/db-3.2.9-r7/work/db-3.2.9/dist' Size: 4096 Blocks: 16 IO Block: 4096 Directory Device: 308h/776d Inode: 303487 Links: 5 Access: (0775/drwxrwxr-x) Uid: ( 250/ portage) Gid: ( 250/ portage) because the db-3.2.9/dist directory is world writable grsecurity stops any binary not owned by root that starts out of it. I know this is not actually a gentoo bug, but I think it would be wise to simply `find $PORTAGE_TMPDIR/$PACKAGE/work -type d -exec bash -c 'chmod 755 {}' \;` any unpacked source before trying to compile. This would make any kind of TPE related issue a thing of the past. I cannot think of any reason not to change the permissions, but that doesn't mean much ;) bye peter Reproducible: Always Steps to Reproduce: 1. 2. 3.
umm that might mess up permissions of the final installed package ...
This is just the behavior of TPE. I would not expect gentoo to behave in any such way to comply with TPE because well lets face it, why should we trust portage to be TRUSTED? If your willing to code/provide a tested FEATURE to get portage to comply then we will/may consider. Till then I'm marking this bug as NEEDINFO
i also think we should not bend the rules of TPE and give the 'trusted' label to portage, but we can fix a glitch that is present in some packages (i have encountered about 4 of them, but only db comes to my mind right now). let's say the glitch is that the developer forgot to adjust the permissions before rolling his tarball. i see 3 ways for dealing with this: 1. global change in the emerge script by using something in the line of <os.execv> well_known_binaries="configure config.sh" for i in ${well_known_binaries}; do find ./ -type f -name ${i} -exec bash -c 'chmod 755 `dirname {}`' \; done <\os.execv> somewhere in def merge(). i presume this should not iterfere in any way with the permissions of the installed version, since this directory has nothing to do with the final installed package. 2. individual fixes (in ebuilds) for packages that are found to behave not normaly with TPE, either by checking for the error level given by configure (and if it's 126 to the chmod and retry), or by adjusting a few directories from the beginning. 3. the unfortunate solution of disabling userpriv.
petre If you feel gentoo needs this then please make a patch that would demonstrate the proposed functionality. I would assume you would want to dig around in the unpack() or econf() functions of ebuild.sh
petre, Any comments? I kind of like to having bugs that are assigned to me closed rather quickly and I don't want to mark this as invalid, or workforsome. So I'll restate that patches are welcome to either portage itself or the offending ebuilds.
well, I don't have a python wizard hat and right now I have no time in acquiring one. truly sorry. please close the bug if you feel like.
petre, Could you try this non python solution and tell me if it fixes the breakage. open your fav editor on /usr/sbin/ebuild.sh look for the dyn_unpack() function on or around line 456, scroll down to the end of the function to echo ">>> Source unpacked." cd $BUILDDIR trap SIGINT SIGQUIT And add this at the very end of the function. find . -type f \( -name configure -o -name config.sh \) -exec bash -c 'chmod 755 `dirname {}`' \; Note: (I dont have TPE enabled so I cant really verify)
Better yet.. If a pkg comes has world writeable permissions this problem should be reported to the upstream maintainers. I'll recant on the 755 fix and would opt for more of a work around that did o-w on dirs.
The ideal fix here will be to have the upstream maintainers fix the packages vs doing portage hacks. I guess I'll change resolution here to WORKFORSOME
