1 |
Ciaran McCreesh wrote: |
2 |
> On Thu, 08 Nov 2007 18:22:48 +0000 |
3 |
> Steve Long <slong@××××××××××××××××××.uk> wrote: |
4 |
>> > if [[ ${UID} -ne 0 ]]; then |
5 |
>> > |
6 |
>> > We've always told people not to do that. Capabilities required by |
7 |
>> > eselect modules should be tested by attempting to perform the |
8 |
>> > action, not by some arbitrary query done on UIDs or groups. Being |
9 |
>> > UID 0 doesn't mean you're allowed to do something, and not being |
10 |
>> > UID 0 doesn't mean you're not allowed to do something. |
11 |
>> > |
12 |
>> I've always used EUID for the root check, eg: |
13 |
> |
14 |
> Which is just as bad. |
15 |
> |
16 |
No, it's better for the reason given: it doesn't require login as root. Use |
17 |
of ((EUID)) is also quicker. |
18 |
|
19 |
>> This won't get round capabilities (so error status should still be |
20 |
>> checked and the script bail with appropriate output, if it can't do |
21 |
>> something it's supposed to) but it's sufficient for root privilege |
22 |
>> check, and is better than UID which requires login as root. This |
23 |
>> doesn't, of course, deal with non-root users, eg where users in group |
24 |
>> portage are allowed to carry out a task. |
25 |
> |
26 |
> Except you absolutely never should be checking for root. You should be |
27 |
> checking for capabilities. |
28 |
> |
29 |
Whatever. Requiring root for certain tasks has a long history: I didn't make |
30 |
a value judgement, merely pointed out that there is a better method built |
31 |
in to BASH. Further, group membership, while not as fine-grained as ACLs or |
32 |
Linux Capabilities, is still a legitimate security mechanism. Just because |
33 |
it was invented more than ten years ago, that doesn't make it useless. |
34 |
|
35 |
>> You can check for that kind of thing with a writeable test, eg: |
36 |
>> [[ -w $PORTDIR ]] || die 'Write access to portage dir required" |
37 |
> |
38 |
> -w is not reliable. |
39 |
> |
40 |
How so? |
41 |
|
42 |
<lhunath> igli: looks pretty reliable to me. |
43 |
<igli> yer me too lhunath |
44 |
<lhunath> lhunath@avaria ~ $ ll /tmp/a |
45 |
<lhunath> -rw-rw-rw- 1 root root 0 2007-11-11 09:50 /tmp/a |
46 |
<lhunath> lhunath@avaria ~ $ [[ -w /tmp/a ]]; echo $? |
47 |
<lhunath> 1 |
48 |
<lhunath> lhunath@avaria ~ $ echo a > /tmp/a |
49 |
<lhunath> -bash: /tmp/a: Permission denied |
50 |
<lhunath> igli: that example is with grsec turned on making /tmp/a |
51 |
unwritable. |
52 |
<lhunath> so -w seems to take even grsec into account. |
53 |
|
54 |
>> Wrt signalling die, the correct way for a script to terminate on |
55 |
>> signal is something like this code, taken from a SIG_INT handler: |
56 |
>> trap INT |
57 |
>> kill -INT $$ |
58 |
>> This ensures the parent process is correctly notified. So IOW just |
59 |
>> kill self with the appropriate signal, ensuring any traps are cleared. |
60 |
> |
61 |
> No it isn't. |
62 |
Yes it is. I was talking about handling signals, which you appear to have |
63 |
missed. It's not common knowledge so I thought I'd share it. (For those who |
64 |
care about code, you can kill $$ from a subshell too, to signal the |
65 |
_parent_ process.) |
66 |
|
67 |
> When it comes to die, from bad implementations to good |
68 |
> implementations, the order goes: the original drobbins prefix die sucks |
69 |
> more than the original agriffis die, which sucks more than my original |
70 |
> signalling eselect die, which sucks more than the current signalling |
71 |
> paludis die. As time goes on we're finding better and better tricks to |
72 |
> work around bash's lack of exceptions; eselect is currently one |
73 |
> generation behind the best current known solution. |
74 |
> |
75 |
Thing is you never, ever post code, or discuss actual solutions at a |
76 |
technical level, beyond simply saying everyone else is wrong. As such I |
77 |
find your posts devoid of technical content, and negative. I'll leave it at |
78 |
that; bear in mind I won't be responding unless you actually *present* and |
79 |
discuss code solutions (beyond simply saying they "suck" or yet again |
80 |
*yawn* marketing paludis while refusing to discuss /how/ or /why/ its |
81 |
algorithms are better.) |
82 |
|
83 |
BTW people have implemented many correct solutions without exceptions. You |
84 |
clearly still have much to learn from those who came before you. |
85 |
|
86 |
|
87 |
-- |
88 |
gentoo-dev@g.o mailing list |