1 |
On Sun, 11 Nov 2007 09:43:49 +0000 |
2 |
Steve Long <slong@××××××××××××××××××.uk> wrote: |
3 |
> > Which is just as bad. |
4 |
> > |
5 |
> No, it's better for the reason given: it doesn't require login as |
6 |
> root. |
7 |
|
8 |
And it's still checking the wrong thing. |
9 |
|
10 |
> Use of ((EUID)) is also quicker. |
11 |
|
12 |
Quicker than what? It's quicker than the almost-as-bad [[ -w ]] because |
13 |
it doesn't check things. Being EUID 0 does not mean you can write to |
14 |
anything you want. Having [[ -w ]] does not mean you can write to |
15 |
anything you want either, of course, but it's a slight step up from |
16 |
EUID. |
17 |
|
18 |
Checking for EUID or UID or anything else as Donnie was proposing is |
19 |
wrong anyway, for a very simple reason. Consider, for example, eselect |
20 |
kernel. Requiring ROOT to change the /usr/src/linux symlink is a |
21 |
nuisance, since any responsible user will have all of /usr/src managed |
22 |
by a normal user. |
23 |
|
24 |
> Whatever. Requiring root for certain tasks has a long history: |
25 |
|
26 |
On the kernel side. |
27 |
|
28 |
> Further, group membership, while not as fine-grained as ACLs or Linux |
29 |
> Capabilities, is still a legitimate security mechanism. |
30 |
|
31 |
Which isn't what eselect is providing. eselect has nothing to do with |
32 |
security. |
33 |
|
34 |
> >> You can check for that kind of thing with a writeable test, eg: |
35 |
> >> [[ -w $PORTDIR ]] || die 'Write access to portage dir required" |
36 |
> > |
37 |
> > -w is not reliable. |
38 |
> > |
39 |
> How so? |
40 |
|
41 |
There are three very obvious ways in which [[ -w ]] can be wrong. |
42 |
|
43 |
Way the first: the target appears writable, but isn't. A simple example |
44 |
is /dev/full. |
45 |
|
46 |
Way the second: bash does not know how to check for permissions on the |
47 |
target. A simple example is where you're mounting NFS off a server that |
48 |
uses additional security mechanisms that aren't understood by NFS. |
49 |
|
50 |
Way the third, which is extremely important and has worrying |
51 |
implications for security: there is a time delay between when [[ -w ]] |
52 |
is run and when you do whatever it is you're doing. |
53 |
|
54 |
> > When it comes to die, from bad implementations to good |
55 |
> > implementations, the order goes: the original drobbins prefix die |
56 |
> > sucks more than the original agriffis die, which sucks more than my |
57 |
> > original signalling eselect die, which sucks more than the current |
58 |
> > signalling paludis die. As time goes on we're finding better and |
59 |
> > better tricks to work around bash's lack of exceptions; eselect is |
60 |
> > currently one generation behind the best current known solution. |
61 |
> > |
62 |
> Thing is you never, ever post code, or discuss actual solutions at a |
63 |
> technical level, beyond simply saying everyone else is wrong. |
64 |
|
65 |
Well, you're jumping in on a discussion about die implementations, so I |
66 |
assume you're fully aware of the relative merits and implementation |
67 |
details of all four solutions already. But if you're not... Try |
68 |
pointing out which the four solutions don't you recognise and |
69 |
understand. Explaining the implications of any one of them is |
70 |
non-trivial, so it's not something I'll do unnecessarily. |
71 |
|
72 |
> BTW people have implemented many correct solutions without |
73 |
> exceptions. You clearly still have much to learn from those who came |
74 |
> before you. |
75 |
|
76 |
...Or maybe you really don't know the history of die implementations, |
77 |
because that's an insane claim to make. So, the things you should have |
78 |
known before you jumped in on a discussion about die implementations: |
79 |
|
80 |
The original 'die' wasn't 'die'. It was a prefix alias. |
81 |
|
82 |
The prefix alias had all kinds of issues, which were documented by |
83 |
agriffis in his proposal for 'die'. This is mostly the same 'die' you |
84 |
see in Portage and Pkgcore these days. |
85 |
|
86 |
That die function has a long list of conditions it can't handle |
87 |
correctly. When developing eclectic (which became eselect), I needed |
88 |
something better because every module call to die would be under one |
89 |
of those conditions. That was the original signal-die implementation, |
90 |
which worked for what it needed to do at the time. (It also introduced |
91 |
stack traces, which made their way into Portage.) |
92 |
|
93 |
Unfortunately, although it would die reliably, because of various bash |
94 |
implementation quirks, it would sometimes drop the friendly messages |
95 |
and merely show a 'Killed' message. The version currently included in |
96 |
Paludis is a refined version of the eselect implementation that doesn't |
97 |
have the message dropping problem. Hence why I suggested copying the |
98 |
changes for eselect. |
99 |
|
100 |
And there are *still* issues with the newer signalling solutions due to |
101 |
the limitations of Unix signals. Fortunately, any code that could |
102 |
possibly trigger any of those limitations is illegal in ebuilds (but |
103 |
not in eselect modules); unfortunately, people do it by accident anyway. |
104 |
|
105 |
So how, exactly, do I have something to learn from those before me? And |
106 |
why do you feel the need to comment when you don't know what the |
107 |
eselect die implementation is or how the changes to it introduced in |
108 |
Paludis make it better? |
109 |
|
110 |
-- |
111 |
Ciaran McCreesh |