Gentoo Archives: gentoo-dev

From: Steve Long <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Re: eselect_zenity: alpha eselect GUI
Date: Sun, 11 Nov 2007 09:42:50
Message-Id: fh6ikp$kvg$1@ger.gmane.org
In Reply to: Re: [gentoo-dev] Re: eselect_zenity: alpha eselect GUI by Ciaran McCreesh
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

Replies

Subject Author
[gentoo-dev] Re: eselect_zenity: alpha eselect GUI Christian Faulhammer <opfer@g.o>
Re: [gentoo-dev] Re: Re: eselect_zenity: alpha eselect GUI Ciaran McCreesh <ciaran.mccreesh@×××××××××××××.uk>