1 |
On Mon, 12 Nov 2007 09:13:32 +0000 |
2 |
Steve Long <slong@××××××××××××××××××.uk> wrote: |
3 |
> >> Use of ((EUID)) is also quicker. |
4 |
> > |
5 |
> > Quicker than what? |
6 |
> |
7 |
> Than [[ ${UID} -ne 0 ]] ie the existing code. What did you think the |
8 |
> discussion was about? |
9 |
|
10 |
Well, I was kind of wondering... Because it looked to me like you were |
11 |
implying that EUID is faster than UID. Which is clearly untrue... |
12 |
|
13 |
> > It's quicker than the almost-as-bad [[ -w ]] because |
14 |
> > it doesn't check things. Being EUID 0 does not mean you can write to |
15 |
> > anything you want. Having [[ -w ]] does not mean you can write to |
16 |
> > anything you want either, of course, but it's a slight step up from |
17 |
> > EUID. |
18 |
> |
19 |
> Sure, since you don't check [[ -w ]] you check [[ -w path ]]. |
20 |
|
21 |
...which is exactly what we were discussing, as you know fine well. |
22 |
|
23 |
> > Checking for EUID or UID or anything else as Donnie was proposing is |
24 |
> > wrong anyway, for a very simple reason. Consider, for example, |
25 |
> > eselect kernel. Requiring ROOT to change the /usr/src/linux symlink |
26 |
> > is a nuisance, since any responsible user will have all of /usr/src |
27 |
> > managed by a normal user. |
28 |
> > |
29 |
> Indeed; and all I did was a) present a better way to write the |
30 |
> existing check, and b) mention a better test that could be used, |
31 |
> which you are now discussing (for a change.) |
32 |
|
33 |
The existing check is completely wrong. You're presenting a less |
34 |
readable but marginally faster incorrect alternative in a place where |
35 |
a small constant performance factor gain is irrelevant. |
36 |
|
37 |
> >> Whatever. Requiring root for certain tasks has a long history: |
38 |
> > |
39 |
> > On the kernel side. |
40 |
> |
41 |
> Hmm, I'm sure I've used several apps which required root over the |
42 |
> years. |
43 |
|
44 |
Then get them fixed. |
45 |
|
46 |
> >> Further, group membership, while not as fine-grained as ACLs or |
47 |
> >> Linux Capabilities, is still a legitimate security mechanism. |
48 |
> > |
49 |
> > Which isn't what eselect is providing. eselect has nothing to do |
50 |
> > with security. |
51 |
> > |
52 |
> So what? The system still needs to be secured, and the user who runs |
53 |
> eselect does require certain privileges, which is very much the |
54 |
> purview of security. |
55 |
|
56 |
And there is no correct way to test whether those privileges are |
57 |
available using bash, which brings us back to my original point. |
58 |
|
59 |
> I thought you were going to mention the latter two; the question |
60 |
> remains: why not just do so in the first place, in the spirit of |
61 |
> communication and development? |
62 |
|
63 |
Because I assume I'm dealing with an audience that more or less |
64 |
understands the topic at hand and doesn't need every single detail |
65 |
explicitly spelt out. |
66 |
|
67 |
> None of the above stop a writeable check being useful imo: if the |
68 |
> permission isn't there as far as the kernel's concerned, there's no |
69 |
> point trying the rest of it. |
70 |
|
71 |
Except that [[ -w ]] can return false negatives. |
72 |
|
73 |
> > Well, you're jumping in on a discussion about die implementations, |
74 |
> > so I assume you're fully aware of the relative merits and |
75 |
> > implementation details of all four solutions already. But if you're |
76 |
> > not... Try pointing out which the four solutions don't you |
77 |
> > recognise and understand. Explaining the implications of any one of |
78 |
> > them is non-trivial, so it's not something I'll do unnecessarily. |
79 |
> > |
80 |
> Don't bother: for some reason I don't feel very motivated by |
81 |
> this "conversation". I was discussing how to handle signals, btw, and |
82 |
> sharing something I learnt with others (which you clearly did not know |
83 |
> yourself.) |
84 |
|
85 |
Had you bothered to study any of the newer die implementations, you'd |
86 |
realise that I know exactly how all that works. |
87 |
|
88 |
> > So how, exactly, do I have something to learn from those before me? |
89 |
> |
90 |
> Your statement that BASH's lack of exceptions means you cannot |
91 |
> implement correct solutions tells me you have much to learn |
92 |
> technically |
93 |
|
94 |
Not at all. If you think they can, it shows you don't know enough about |
95 |
Unix signal handling and obscure-but-sadly-common side cases. |
96 |
|
97 |
> quite apart from the social issues which have already been documented |
98 |
> and discussed ad nauseam. |
99 |
|
100 |
Repeating something over and over doesn't make it true. |
101 |
|
102 |
> > And why do you feel the need to comment when you don't know what the |
103 |
> > eselect die implementation is or how the changes to it introduced in |
104 |
> > Paludis make it better? |
105 |
> > |
106 |
> As stated, I was sharing knowledge and pointing out improvements and |
107 |
> possible solutions. |
108 |
|
109 |
You don't know what the existing solution is or what the improved |
110 |
solution being proposed is, so how can you point out improvements? |
111 |
|
112 |
> You should try it some time |
113 |
|
114 |
Funnily enough, that's exactly what I did when I suggested moving from |
115 |
the original eselect implementation to the newer Paludis implementation. |
116 |
|
117 |
> (nice to see that you |
118 |
> can actually discuss, as above, but it's a shame it still takes 2 or |
119 |
> 3 mails before you will. Good luck with that.) |
120 |
|
121 |
Mmm, let's see. |
122 |
|
123 |
First email: suggested moving from the original eselect die to the |
124 |
newer Paludis die. More than enough information there for anyone |
125 |
involved in the discussion to understand and make the changes. |
126 |
|
127 |
Your reply: missing the point about signals, and getting it wrong, |
128 |
without understanding what the two different methods are. |
129 |
|
130 |
Second email: me giving you a convenient list of the die |
131 |
implementations that you should have studied before jumping in to begin |
132 |
with. |
133 |
|
134 |
Your reply: claiming that said convenient list isn't posting code, when |
135 |
in fact it's a list of bits of code that you should have read before |
136 |
offering 'suggestions' (translation: trying to show off when you don't |
137 |
actually know what's being discussed). Following up with a claim that |
138 |
people have implemented correct solutions, where you yourself neither |
139 |
post code nor state where such solutions exist. |
140 |
|
141 |
Third email: telling you even more explicitly the things you should |
142 |
have known before jumping in. |
143 |
|
144 |
Your reply: silly trolling repeating claims that people make when they |
145 |
realise they've made a fool of themselves and are trying to shift it |
146 |
into making me look bad. Nobody falls for that any more. |
147 |
|
148 |
-- |
149 |
Ciaran McCreesh |