1 |
On Thu, 08 Nov 2007 18:22:48 +0000 |
2 |
Steve Long <slong@××××××××××××××××××.uk> wrote: |
3 |
> > if [[ ${UID} -ne 0 ]]; then |
4 |
> > |
5 |
> > We've always told people not to do that. Capabilities required by |
6 |
> > eselect modules should be tested by attempting to perform the |
7 |
> > action, not by some arbitrary query done on UIDs or groups. Being |
8 |
> > UID 0 doesn't mean you're allowed to do something, and not being |
9 |
> > UID 0 doesn't mean you're not allowed to do something. |
10 |
> > |
11 |
> I've always used EUID for the root check, eg: |
12 |
|
13 |
Which is just as bad. |
14 |
|
15 |
> This won't get round capabilities (so error status should still be |
16 |
> checked and the script bail with appropriate output, if it can't do |
17 |
> something it's supposed to) but it's sufficient for root privilege |
18 |
> check, and is better than UID which requires login as root. This |
19 |
> doesn't, of course, deal with non-root users, eg where users in group |
20 |
> portage are allowed to carry out a task. |
21 |
|
22 |
Except you absolutely never should be checking for root. You should be |
23 |
checking for capabilities. |
24 |
|
25 |
> You can check for that kind of thing with a writeable test, eg: |
26 |
> [[ -w $PORTDIR ]] || die 'Write access to portage dir required" |
27 |
|
28 |
-w is not reliable. |
29 |
|
30 |
> Wrt signalling die, the correct way for a script to terminate on |
31 |
> signal is something like this code, taken from a SIG_INT handler: |
32 |
> trap INT |
33 |
> kill -INT $$ |
34 |
> This ensures the parent process is correctly notified. So IOW just |
35 |
> kill self with the appropriate signal, ensuring any traps are cleared. |
36 |
|
37 |
No it isn't. When it comes to die, from bad implementations to good |
38 |
implementations, the order goes: the original drobbins prefix die sucks |
39 |
more than the original agriffis die, which sucks more than my original |
40 |
signalling eselect die, which sucks more than the current signalling |
41 |
paludis die. As time goes on we're finding better and better tricks to |
42 |
work around bash's lack of exceptions; eselect is currently one |
43 |
generation behind the best current known solution. |
44 |
|
45 |
-- |
46 |
Ciaran McCreesh |