Summary: | Supplementary groups aren't set when changing to portage user | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | petre rodan (RETIRED) <kaiowas> |
Component: | [OLD] Core system | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | oldium.pro |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Other | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch to set supplementary groups |
Description
petre rodan (RETIRED)
2005-06-30 04:43:30 UTC
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 ;) |