Looking at some random examples of RESTRICT=userpriv: 1. nvidia/CUDA ebuilds require access to /dev/nvidia*. This either requires portage to be in the 'video' group (which we don't have any sane way of enforcing) or using root privileges. 2. some game ebuilds are unable to access tools other game ebuilds installed (due to 'games' group requirement). So the ebuilds run those tools as root to circumvent their own limitation. 3. qmail-related ebuilds seem to have a similar issue but I don't know the details (yet). That said, I'd dare say a lot of RESTRICT=userpriv cases could be avoided if ebuilds were able to force supplementary groups during the build. An ugly syntax would be: SUPPLEMENTARY_GROUPS="video,games" that would cause portage to call setgroups() with the two listed groups. Therefore, the ebuild would be able to access the needed resources without needing to be given superuser privileges.
Do not interpret this comment as pro or con, I'm on the fence, but adding information. This needs to roll around in my head a bit, but here is what I've done for cuda/opencl ebuilds. I've added a note in the ebuild on failure that says "please ensure portage is in the video group" and I've used "addwrite" to allow access to the needed device nodes. Perfect? No, but it does work. It might be useful if the "SUPPLIMENTORY_GROUPS" (or w/e) option was able to check if portage was in the group and warn the user they need to add portage to that group. Automatically adding portage to that group is basically as bad as just allowing root in the first place imho.
Just to be clear, it's not supposed to modify passwd. It uses the setgroups() call to set groups 'seen' by the process.
SUPPLEMENTARY_GROUPS=wheel,root would replace the undesired RESTRICT=userpriv and we are back in the same place.
(In reply to Rick Farina (Zero_Chaos) from comment #3) > SUPPLEMENTARY_GROUPS=wheel,root would replace the undesired > RESTRICT=userpriv and we are back in the same place. That wouldn't be equivalent and I don't see why you would do that. So maybe another thing to be clear: I'm not saying 'replace completely'. Just provide a safer alternative where it's possible.
Isn't this overkill, given that there are only 10 packages in the tree with RESTRICT=userpriv (and even fewer are free software).
(In reply to Ulrich Müller from comment #5) > Isn't this overkill, given that there are only 10 packages in the tree with > RESTRICT=userpriv (and even fewer are free software). Yes and no. There are other things which are broken with slightly crazy workarounds like erroring and asking the user to add portage to video group (that's how I fix a bunch of opencl/cuda issues). This is a nice new feature imho.
