Hello, developers. I've been doing some research wrt use of RESTRICT=userpriv [1] lately and found out that most of the affected packages use it solely to gain access to files or devices that are restricted to specific groups. I've specifically noted three cases:
1) ebuilds using CUDA that needed to access /dev/nvidia* (restricted to video group), 2) game ebuilds that needed to access game executables (restricted to games group but hopefully subject to change), 3) qmail-related ebuilds that needed to access restricted files (no details yet). I believe that most (if not all) of uses of RESTRICT=userpriv are overkill. It implies elevating privileges for the whole build process while what's really needed is an access to a particular file or device, or a capability of some kind for a single command execution. I would therefore like to ask the Community for ideas on how RESTRICT=userpriv could be effectively replaced by something safer. I can enumerate the following possibilities: a) explicitly requesting user to alter group membership for the build user. This is already done in some of the CUDA ebuilds. Advantages: - limits elevated privileges to a particular group access, - works now. Disadvantages: - requires manual intervention (we even can't properly name the user since there's no PMS function/variable to obtain it), - increases privileges for all ebuilds rather than the one needing it. Developers using it will not get proper failures for ebuilds not having the check, - doesn't cover other uses of FEATURES=userpriv. b) SUPPLEMENTARY_GROUPS support [2]. The idea is to use setgroups() to transparently enable group membership for the build process. Advantages: - transparent, relatively simple. Disadvantages: - quite ugly name ;), - doesn't cover other uses of FEATURES=userpriv. c) 'esudo' helper [3]. This is a more generic form of (2), with support for other potential privilege changes. Advantages: - allows to raise privileges precisely for one command, - flexible -- may alter EUID, EGID, groups, capabilities. Disadvantages: - hard to implement -- especially if we want to make it capable of running bash functions. What do you think? Do you have other ideas? [1]:https://bugs.gentoo.org/show_bug.cgi?id=516568 [2]:https://bugs.gentoo.org/show_bug.cgi?id=516614 [3]:https://bugs.gentoo.org/show_bug.cgi?id=516616 -- Best regards, Michał Górny
signature.asc
Description: PGP signature
