Alexander Mieland posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 20 Jan 2005 08:40:38 +0100:
> As you surely have read in one or two of the mails before, some people > wouldn't place either the user or the client into the portage group. And I > don't want this too, because I think the portage group should only be for > gentoo-related portage-tools and not for such a statistics tool which has > nothing to do with portage. > > Some other people also don't want the user who runs basc to be able to > emerge something what can be possible if he is in the portage group I > think. But I'm not sure if he would be able to emerge something then. Being in the portage group won't allow emerging, because one must have root privs in ordered to complete the qmerge to the live system. It simply allows users in that group to access merge statistics and get a bit more detailed info on what is currently merged and what is not. That in fact is the whole point of FEATURES=userpriv, doing the compile and install ebuild steps as the portage user/group, so as not to allow uncontrolled access to the system, rather than as root, with a sandbox. The actual qmerge step must still be done as root in ordered to be able to write to the various system dirs and make various permissions changes as necessary. However, one thing the portage group WILL allow, is writing to the portage $DISTDIR where sources are stored. While these /are/ normally md5 verified, being in the portage group appears to allow ebuild digesting also, so anyone in the portage group could substitute their own trojaned sources and redigest the ebuild, potentially compromising the system by causing a routine emerge to use compromised sources. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin -- [email protected] mailing list
