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