in portage_exec.py, you have os.setgroups(groups) that should be designed to set the supplementaly group IDs for portage, and not the portage group itself. I have the portage user in 2 groups: pandora ~ # id portage uid=250(portage) gid=250(portage) groups=250(portage),1005(grsec) and I need setgroups to also use the secondary group (grsec), because: pandora ~ # cat /proc/sys/kernel/grsecurity/tpe_restrict_all 1 pandora ~ # cat /proc/sys/kernel/grsecurity/tpe 1 pandora ~ # cat /proc/sys/kernel/grsecurity/tpe_gid 1005 pandora ~ # emerge findutils [..] * econf: updating findutils-4.1.20/config.sub with /usr/share/gnuconfig/config.sub ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --build=i686-pc-linux-gnu --enable-nls /usr/lib/portage/bin/ebuild.sh: ./configure: /bin/sh: bad interpreter: Permission denied !!! ERROR: sys-apps/findutils-4.1.20-r1 failed. !!! Function econf, Line 485, Exitcode 0 !!! econf failed !!! If you need support, post the topmost build error, NOT this status message. # dmesg grsec: From 10.0.1.4: denied untrusted exec of /var/tmp/portage/findutils-4.1.20-r1/work/findutils-4.1.20/configure by /usr/lib/portage/bin/ebuild.sh[ebuild.sh:14196] uid/euid:250/250 gid/egid:250/250, parent /usr/lib/portage/bin/ebuild.sh[ebuild.sh:5799] uid/euid:250/250 gid/egid:250/250 if the grsec group would have been used in os.setgroups everything would have been perfect ;) Portage 2.0.51.22-r1 (selinux/2004.1/x86, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.11-hardened-r15-sunspire i686) ================================================================= System uname: 2.6.11-hardened-r15-sunspire i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.6.12 dev-lang/python: 2.2.3-r5, 2.3.5 sys-apps/sandbox: 1.2.9 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=i686 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/alias /var/qmail/control /var/service" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=i686 -O3 -pipe -fomit-frame-pointer" DISTDIR="/var/share/ftp/0/gentoo/distfiles" FEATURES="autoconfig distlocks sandbox selinux sfperms strict userpriv" GENTOO_MIRRORS="ftp://ftp.lug.ro/gentoo/ http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage_2" SYNC="rsync://rsync.ro.gentoo.org/gentoo-portage" USE="crypt curl gd gdbm hardened hardenedphp ldap libwww ncurses nls pam perl pic pie png python readline samba selinux spamassassin ssl tcpd x86 zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS
some great feedback from #gentoo-hardened: <johnm> kaiowas: the problem with that is that usersin the grsec group would also have access which is normally only allowed by portage. no? <kaiowas> johnm, well, users in the grsec group are only very-trusted users that don't play nice with TPE restrictions. on most of my machines portage is the only one in that group <kaiowas> do you see another solution? (except echo 250 > /proc/sys/kernel/grsecurity/tpe_gid) <johnm> not really, but I dont think portage should be setting ownership to a random group portage is part of <johnm> it might be possible to have portage redefine the portage group ID via make.conf <johnm> which would be nicer <johnm> that way you can specifically change the gid for portage to say, that of grsec. <johnm> portage:<userspecifiedgroup> is better then portage:<random group portage is part of> I agree that a configurable group (that defaults to portage in case userpriv is used) is a cleaner solution. what do you think?
Group portage is not "some random group". To begin with, it is used to dictate which users can fetch and update the cache. There's more than this that I can't think of right now. What exactly is it that you are trying to do?
I am trying to use the 'userpriv' feature on a TPE-enabled grsec system. in order for this to work there are 2 solutions: 1. make os.setgroups actually set supplementaly group IDs for portage (see comment #0 ). In this case the user only has to run 'usermod -G grsec portage'. or 2. make it possible to the user to select the gid in which portage will run in. (see comment #1 ). In this case you should provide a configurable option in make.conf and let the user change the gid of portage: #portage_gid=portage portage_gid=grsec It would be cool to have this fixed, and IMHO the first possibility is much easier to implement.
Much easier and much safer.
I have very similar problem. My mounted device, where I compile things, is not listable for everybody (read permission is not set for others, only for group 'data'). But currently perl version 5.8.6 fails to compile, when there is such directory - problem reported in bug #97671. Adding user 'portage' into my group 'data' doesn't help, because emerge uses only the group 'portage' - this is wrong according to my /etc/group. For me there is no good workaround, only make my mounted device world readable!
Created attachment 106486 [details, diff] Patch to set supplementary groups This patch takes the easy way and sets all groups of the requested uid in _exec(). If the caller passes in its own list of groups or doesn't request a uid change it doesn't change the old behavior.
Everyoneone who is affected by this problem please test the attached patch or provide detailed testcase as I'm not 100% sure that this is the correct solution.
This is a duplicate if bug #137610 and it's already been fixed since 2.1.2_pre3-r6.
*** This bug has been marked as a duplicate of bug 137610 ***
portage-2.1.2-r9 has this bug fixed. thanks ;)
