Just putting in my two cents:

I think we should either make functions that do the chown stuff, like
fperms does, or add functions like get_root_uid.  If the permissions are
set, this usually means they aren't set correctly from the ebuild
perspective.  portage_uid != root_uid, but a function like get_root_uid
could easily do some if-ing on platforms, and also get around the ugly 0
workaround for Solaris/Darwin/FreeBSD where the root group is not
'root', but sys, wheel, or whatever.


On 11-04-2007 09:04:29 -0400, Armando Di Cianno wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
> 
> 
>  On Apr 11, 2007, at 6:05 AM, Michael Haubenwallner wrote:
> > Thing is that 'chown -R root:0' works on linux, while on non-linux it
> > does not.
> >
> > I'm unsure how to do in prefix:
> > 1) avoid chown in prefix (as the patch does currently)
> > 2) chown to "$PORTAGE_INST_USER:$PORTAGE_INST_GID" instead of "root:0"
> 
>  This has been perennial question for me, since I starting moving many 
>  ebuilds to prefix, so I'd like to start a discussion on it.
> 
>  Obviously, user-privilege use of prefix-portage is sort the main way, as far 
>  as I can tell, that people use it right now.  As a hack -- and as I mainly 
>  work on Darwin, atm -- I've been wrapping or skipping 
>  chown/chmod/fperms/etceteras calls in 'if [ "${KERNEL}" == "Darwin" ]', and 
>  ewarn'ng that "this operation is not happening'.  This has worked -- as a 
>  hack --but raises some questions: if a package requires a change of 
>  permission for security reasons, especially, it can be considered blatantly 
>  wrong to _not_ be doing the change of permissions.
> 
>  Also, I'd like prefix-portage to work in the classic way as root, or with 
>  sudo, as well as fully working for a normal, non-privileged user.
> 
>  Now, a number of packages simply want to ensure that they have a user to run 
>  as, and the directories/homes/whatever are owned by that user.  In this 
>  case, working with user privileges, it's easy enough to ensure installed 
>  files bear the permissions of the user running emerge.
> 
>  For packages that practically *require* permission changes, I suggest 
>  something like the following; if we can inject userpriv as the 'default' 
>  into FEATURES, we can simply RESTRICT these temperamental-security-wise 
>  ebuilds with userpriv.
> 
>  If we do something like the above, we can easily move all the 
>  chown/chmod/fperms calls to "echown, echmod, efperms" and have these 
>  decisions happen in the background (or tossing an error that sudo is 
>  required or something).
> 
>  Specifics aside, I'd like to know if this is generally the idea most of us 
>  have in our heads about how prefix-portage should work.  And then, 
>  specifically, I wonder if we can co-opt 'userpriv' in that way, since it 
>  seems pretty apt to be used in this fashion.
> 
>  __armando
>  aka fafhrd
> 
>  -----BEGIN PGP SIGNATURE-----
>  Version: GnuPG v1.4.6 (Darwin)
> 
>  iD8DBQFGHNzg1uuRqaoClwIRAhBUAJoCap/qHrjoWgmqX13hUmNhTFWHEgCeJT3D
>  AlUApd1EWMQ1DhskjYjVvP4=
>  =s+bC
>  -----END PGP SIGNATURE-----
>  -- 
>  gentoo-alt@g.o mailing list
> 

-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-alt@g.o mailing list