1 |
Just putting in my two cents: |
2 |
|
3 |
I think we should either make functions that do the chown stuff, like |
4 |
fperms does, or add functions like get_root_uid. If the permissions are |
5 |
set, this usually means they aren't set correctly from the ebuild |
6 |
perspective. portage_uid != root_uid, but a function like get_root_uid |
7 |
could easily do some if-ing on platforms, and also get around the ugly 0 |
8 |
workaround for Solaris/Darwin/FreeBSD where the root group is not |
9 |
'root', but sys, wheel, or whatever. |
10 |
|
11 |
|
12 |
On 11-04-2007 09:04:29 -0400, Armando Di Cianno wrote: |
13 |
> -----BEGIN PGP SIGNED MESSAGE----- |
14 |
> Hash: SHA1 |
15 |
> |
16 |
> |
17 |
> On Apr 11, 2007, at 6:05 AM, Michael Haubenwallner wrote: |
18 |
> > Thing is that 'chown -R root:0' works on linux, while on non-linux it |
19 |
> > does not. |
20 |
> > |
21 |
> > I'm unsure how to do in prefix: |
22 |
> > 1) avoid chown in prefix (as the patch does currently) |
23 |
> > 2) chown to "$PORTAGE_INST_USER:$PORTAGE_INST_GID" instead of "root:0" |
24 |
> |
25 |
> This has been perennial question for me, since I starting moving many |
26 |
> ebuilds to prefix, so I'd like to start a discussion on it. |
27 |
> |
28 |
> Obviously, user-privilege use of prefix-portage is sort the main way, as far |
29 |
> as I can tell, that people use it right now. As a hack -- and as I mainly |
30 |
> work on Darwin, atm -- I've been wrapping or skipping |
31 |
> chown/chmod/fperms/etceteras calls in 'if [ "${KERNEL}" == "Darwin" ]', and |
32 |
> ewarn'ng that "this operation is not happening'. This has worked -- as a |
33 |
> hack --but raises some questions: if a package requires a change of |
34 |
> permission for security reasons, especially, it can be considered blatantly |
35 |
> wrong to _not_ be doing the change of permissions. |
36 |
> |
37 |
> Also, I'd like prefix-portage to work in the classic way as root, or with |
38 |
> sudo, as well as fully working for a normal, non-privileged user. |
39 |
> |
40 |
> Now, a number of packages simply want to ensure that they have a user to run |
41 |
> as, and the directories/homes/whatever are owned by that user. In this |
42 |
> case, working with user privileges, it's easy enough to ensure installed |
43 |
> files bear the permissions of the user running emerge. |
44 |
> |
45 |
> For packages that practically *require* permission changes, I suggest |
46 |
> something like the following; if we can inject userpriv as the 'default' |
47 |
> into FEATURES, we can simply RESTRICT these temperamental-security-wise |
48 |
> ebuilds with userpriv. |
49 |
> |
50 |
> If we do something like the above, we can easily move all the |
51 |
> chown/chmod/fperms calls to "echown, echmod, efperms" and have these |
52 |
> decisions happen in the background (or tossing an error that sudo is |
53 |
> required or something). |
54 |
> |
55 |
> Specifics aside, I'd like to know if this is generally the idea most of us |
56 |
> have in our heads about how prefix-portage should work. And then, |
57 |
> specifically, I wonder if we can co-opt 'userpriv' in that way, since it |
58 |
> seems pretty apt to be used in this fashion. |
59 |
> |
60 |
> __armando |
61 |
> aka fafhrd |
62 |
> |
63 |
> -----BEGIN PGP SIGNATURE----- |
64 |
> Version: GnuPG v1.4.6 (Darwin) |
65 |
> |
66 |
> iD8DBQFGHNzg1uuRqaoClwIRAhBUAJoCap/qHrjoWgmqX13hUmNhTFWHEgCeJT3D |
67 |
> AlUApd1EWMQ1DhskjYjVvP4= |
68 |
> =s+bC |
69 |
> -----END PGP SIGNATURE----- |
70 |
> -- |
71 |
> gentoo-alt@g.o mailing list |
72 |
> |
73 |
|
74 |
-- |
75 |
Fabian Groffen |
76 |
Gentoo on a different level |
77 |
-- |
78 |
gentoo-alt@g.o mailing list |