1 |
Ciaran McCreesh wrote: |
2 |
> On Sun, 11 Nov 2007 09:43:49 +0000 |
3 |
> Steve Long <slong@××××××××××××××××××.uk> wrote: |
4 |
>> > Which is just as bad. |
5 |
>> > |
6 |
>> No, it's better for the reason given: it doesn't require login as |
7 |
>> root. |
8 |
> |
9 |
> And it's still checking the wrong thing. |
10 |
> |
11 |
Be that as it may, if a scriptwriter is checking for root, that's a better |
12 |
way to do it. |
13 |
|
14 |
>> Use of ((EUID)) is also quicker. |
15 |
> |
16 |
> Quicker than what? |
17 |
Than [[ ${UID} -ne 0 ]] ie the existing code. What did you think the |
18 |
discussion was about? |
19 |
|
20 |
> It's quicker than the almost-as-bad [[ -w ]] because |
21 |
> it doesn't check things. Being EUID 0 does not mean you can write to |
22 |
> anything you want. Having [[ -w ]] does not mean you can write to |
23 |
> anything you want either, of course, but it's a slight step up from |
24 |
> EUID. |
25 |
> |
26 |
Sure, since you don't check [[ -w ]] you check [[ -w path ]]. |
27 |
|
28 |
> Checking for EUID or UID or anything else as Donnie was proposing is |
29 |
> wrong anyway, for a very simple reason. Consider, for example, eselect |
30 |
> kernel. Requiring ROOT to change the /usr/src/linux symlink is a |
31 |
> nuisance, since any responsible user will have all of /usr/src managed |
32 |
> by a normal user. |
33 |
> |
34 |
Indeed; and all I did was a) present a better way to write the existing |
35 |
check, and b) mention a better test that could be used, which you are now |
36 |
discussing (for a change.) |
37 |
|
38 |
>> Whatever. Requiring root for certain tasks has a long history: |
39 |
> |
40 |
> On the kernel side. |
41 |
> |
42 |
Hmm, I'm sure I've used several apps which required root over the years. |
43 |
|
44 |
>> Further, group membership, while not as fine-grained as ACLs or Linux |
45 |
>> Capabilities, is still a legitimate security mechanism. |
46 |
> |
47 |
> Which isn't what eselect is providing. eselect has nothing to do with |
48 |
> security. |
49 |
> |
50 |
So what? The system still needs to be secured, and the user who runs eselect |
51 |
does require certain privileges, which is very much the purview of |
52 |
security. |
53 |
|
54 |
>> >> You can check for that kind of thing with a writeable test, eg: |
55 |
>> >> [[ -w $PORTDIR ]] || die 'Write access to portage dir required" |
56 |
>> > |
57 |
>> > -w is not reliable. |
58 |
>> > |
59 |
>> How so? |
60 |
> |
61 |
> There are three very obvious ways in which [[ -w ]] can be wrong. |
62 |
> |
63 |
> Way the first: the target appears writable, but isn't. A simple example |
64 |
> is /dev/full. |
65 |
> |
66 |
> Way the second: bash does not know how to check for permissions on the |
67 |
> target. A simple example is where you're mounting NFS off a server that |
68 |
> uses additional security mechanisms that aren't understood by NFS. |
69 |
> |
70 |
> Way the third, which is extremely important and has worrying |
71 |
> implications for security: there is a time delay between when [[ -w ]] |
72 |
> is run and when you do whatever it is you're doing. |
73 |
> |
74 |
I thought you were going to mention the latter two; the question remains: |
75 |
why not just do so in the first place, in the spirit of communication and |
76 |
development? |
77 |
|
78 |
None of the above stop a writeable check being useful imo: if the permission |
79 |
isn't there as far as the kernel's concerned, there's no point trying the |
80 |
rest of it. And as I said, errors still need to be checked (which would be |
81 |
your "run it and see.") |
82 |
|
83 |
>> > When it comes to die, from bad implementations to good |
84 |
>> > implementations, the order goes: the original drobbins prefix die |
85 |
>> > sucks more than the original agriffis die, which sucks more than my |
86 |
>> > original signalling eselect die, which sucks more than the current |
87 |
>> > signalling paludis die. As time goes on we're finding better and |
88 |
>> > better tricks to work around bash's lack of exceptions; eselect is |
89 |
>> > currently one generation behind the best current known solution. |
90 |
>> > |
91 |
>> Thing is you never, ever post code, or discuss actual solutions at a |
92 |
>> technical level, beyond simply saying everyone else is wrong. |
93 |
> |
94 |
> Well, you're jumping in on a discussion about die implementations, so I |
95 |
> assume you're fully aware of the relative merits and implementation |
96 |
> details of all four solutions already. But if you're not... Try |
97 |
> pointing out which the four solutions don't you recognise and |
98 |
> understand. Explaining the implications of any one of them is |
99 |
> non-trivial, so it's not something I'll do unnecessarily. |
100 |
> |
101 |
Don't bother: for some reason I don't feel very motivated by |
102 |
this "conversation". I was discussing how to handle signals, btw, and |
103 |
sharing something I learnt with others (which you clearly did not know |
104 |
yourself.) |
105 |
|
106 |
>> BTW people have implemented many correct solutions without |
107 |
>> exceptions. You clearly still have much to learn from those who came |
108 |
>> before you. |
109 |
> |
110 |
> ...Or maybe you really don't know the history of die implementations, |
111 |
> because that's an insane claim to make. |
112 |
<snip> |
113 |
> So how, exactly, do I have something to learn from those before me? |
114 |
|
115 |
Your statement that BASH's lack of exceptions means you cannot implement |
116 |
correct solutions tells me you have much to learn technically, quite apart |
117 |
from the social issues which have already been documented and discussed ad |
118 |
nauseam. |
119 |
|
120 |
> And why do you feel the need to comment when you don't know what the |
121 |
> eselect die implementation is or how the changes to it introduced in |
122 |
> Paludis make it better? |
123 |
> |
124 |
As stated, I was sharing knowledge and pointing out improvements and |
125 |
possible solutions. You should try it some time (nice to see that you can |
126 |
actually discuss, as above, but it's a shame it still takes 2 or 3 mails |
127 |
before you will. Good luck with that.) |
128 |
|
129 |
|
130 |
-- |
131 |
gentoo-dev@g.o mailing list |