maillog: 11/01/2007-17:02:48(+0000): Ciaran McCreesh types > On Thu, 11 Jan 2007 11:56:09 -0500 Mike Frysinger <[EMAIL PROTECTED]> > wrote: > | On Wednesday 10 January 2007 20:01, Ciaran McCreesh wrote: > | > On Wed, 10 Jan 2007 19:56:00 -0500 Mike Frysinger > | > <[EMAIL PROTECTED]> > | > | as stated in original e-mail, unattended/sandbox are just some > | > | examples, not the only ones > | > > | > So which RESTRICT values *should* the user legitimately have to care > | > about? > | > | On Wednesday 10 January 2007 16:40, Chris Gianelloni wrote: > | > I am a user. I don't want any of my compiles executing with > | > elevated privileges. I have FEATURES=userpriv. Package foo has > | > RESTRICT=userpriv. I don't have ACCEPT_RESTRICT=userpriv. When I > | > try to install package foo, it fails, because I don't want to allow > | > RESTRICT=userpriv. > > Bogus argument. If an ebuild were truly doing something naughty with > elevated privs, it could just do it in one of the pkg_ phases. Since > userpriv isn't a security feature, there's no advantage for the end > user in restricting based upon it. > > So again, which RESTRICT variables should the user legitimately have to > care about?
I agree that if an ebuild wants to misbehave it can and there is no stopping it. However, code that is executed in pkg_* is generally restricted to code written by the person who is involved in maintaining the ebuild. It is easy to read that code and see what it does. In contrast, the stuff that is run with lowered privileges is usually coded upstream. I'd like to have that run with lowered privileges, no matter what. -- / Georgi Georgiev / As in certain cults it is possible to kill / \ [EMAIL PROTECTED] \ a process if you know its true name. -- \ / http://www.gg3.net/ / Ken Thompson and Dennis M. Ritchie /
pgpJyKmnbFmRj.pgp
Description: PGP signature
