Ciaran McCreesh wrote:
> On Thu, 08 Nov 2007 18:22:48 +0000
> Steve Long <[EMAIL PROTECTED]> wrote:
>> > if [[ ${UID} -ne 0 ]]; then
>> >
>> > We've always told people not to do that. Capabilities required by
>> > eselect modules should be tested by attempting to perform the
>> > action, not by some arbitrary query done on UIDs or groups. Being
>> > UID 0 doesn't mean you're allowed to do something, and not being
>> > UID 0 doesn't mean you're not allowed to do something.
>> >
>> I've always used EUID for the root check, eg:
>
> Which is just as bad.
>
No, it's better for the reason given: it doesn't require login as root. Use
of ((EUID)) is also quicker.
>> This won't get round capabilities (so error status should still be
>> checked and the script bail with appropriate output, if it can't do
>> something it's supposed to) but it's sufficient for root privilege
>> check, and is better than UID which requires login as root. This
>> doesn't, of course, deal with non-root users, eg where users in group
>> portage are allowed to carry out a task.
>
> Except you absolutely never should be checking for root. You should be
> checking for capabilities.
>
Whatever. Requiring root for certain tasks has a long history: I didn't make
a value judgement, merely pointed out that there is a better method built
in to BASH. Further, group membership, while not as fine-grained as ACLs or
Linux Capabilities, is still a legitimate security mechanism. Just because
it was invented more than ten years ago, that doesn't make it useless.
>> You can check for that kind of thing with a writeable test, eg:
>> [[ -w $PORTDIR ]] || die 'Write access to portage dir required"
>
> -w is not reliable.
>
How so?
<lhunath> igli: looks pretty reliable to me.
<igli> yer me too lhunath
<lhunath> [EMAIL PROTECTED] ~ $ ll /tmp/a
<lhunath> -rw-rw-rw- 1 root root 0 2007-11-11 09:50 /tmp/a
<lhunath> [EMAIL PROTECTED] ~ $ [[ -w /tmp/a ]]; echo $?
<lhunath> 1
<lhunath> [EMAIL PROTECTED] ~ $ echo a > /tmp/a
<lhunath> -bash: /tmp/a: Permission denied
<lhunath> igli: that example is with grsec turned on making /tmp/a
unwritable.
<lhunath> so -w seems to take even grsec into account.
>> Wrt signalling die, the correct way for a script to terminate on
>> signal is something like this code, taken from a SIG_INT handler:
>> trap INT
>> kill -INT $$
>> This ensures the parent process is correctly notified. So IOW just
>> kill self with the appropriate signal, ensuring any traps are cleared.
>
> No it isn't.
Yes it is. I was talking about handling signals, which you appear to have
missed. It's not common knowledge so I thought I'd share it. (For those who
care about code, you can kill $$ from a subshell too, to signal the
_parent_ process.)
> When it comes to die, from bad implementations to good
> implementations, the order goes: the original drobbins prefix die sucks
> more than the original agriffis die, which sucks more than my original
> signalling eselect die, which sucks more than the current signalling
> paludis die. As time goes on we're finding better and better tricks to
> work around bash's lack of exceptions; eselect is currently one
> generation behind the best current known solution.
>
Thing is you never, ever post code, or discuss actual solutions at a
technical level, beyond simply saying everyone else is wrong. As such I
find your posts devoid of technical content, and negative. I'll leave it at
that; bear in mind I won't be responding unless you actually *present* and
discuss code solutions (beyond simply saying they "suck" or yet again
*yawn* marketing paludis while refusing to discuss /how/ or /why/ its
algorithms are better.)
BTW people have implemented many correct solutions without exceptions. You
clearly still have much to learn from those who came before you.
--
[EMAIL PROTECTED] mailing list
