[gentoo-dev] Re: Re: Re: eselect_zenity: alpha eselect GUI

[Steve Long]

Ciaran McCreesh wrote:
> On Sun, 11 Nov 2007 09:43:49 +0000
> Steve Long <slong@××××××××××××××××××.uk> wrote:
>> > Which is just as bad.
>> >
>> No, it's better for the reason given: it doesn't require login as
>> root.
>
> And it's still checking the wrong thing.
>
Be that as it may, if a scriptwriter is checking for root, that's a better
way to do it.
 
>> Use of ((EUID)) is also quicker.
>
> Quicker than what?
Than [[ ${UID} -ne 0 ]] ie the existing code. What did you think the
discussion was about?

> It's quicker than the almost-as-bad [[ -w ]] because
> it doesn't check things. Being EUID 0 does not mean you can write to
> anything you want. Having [[ -w ]] does not mean you can write to
> anything you want either, of course, but it's a slight step up from
> EUID.
>
Sure, since you don't check [[ -w ]] you check [[ -w path ]].

> Checking for EUID or UID or anything else as Donnie was proposing is
> wrong anyway, for a very simple reason. Consider, for example, eselect
> kernel. Requiring ROOT to change the /usr/src/linux symlink is a
> nuisance, since any responsible user will have all of /usr/src managed
> by a normal user.
>
Indeed; and all I did was a) present a better way to write the existing
check, and b) mention a better test that could be used, which you are now
discussing (for a change.)

>> Whatever. Requiring root for certain tasks has a long history:
>
> On the kernel side.
>
Hmm, I'm sure I've used several apps which required root over the years. 

>> Further, group membership, while not as fine-grained as ACLs or Linux
>> Capabilities, is still a legitimate security mechanism.
>
> Which isn't what eselect is providing. eselect has nothing to do with
> security.
>
So what? The system still needs to be secured, and the user who runs eselect
does require certain privileges, which is very much the purview of
security.
 
>> >> 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?
>
> There are three very obvious ways in which [[ -w ]] can be wrong.
>
> Way the first: the target appears writable, but isn't. A simple example
> is /dev/full.
>
> Way the second: bash does not know how to check for permissions on the
> target. A simple example is where you're mounting NFS off a server that
> uses additional security mechanisms that aren't understood by NFS.
>
> Way the third, which is extremely important and has worrying
> implications for security: there is a time delay between when [[ -w ]]
> is run and when you do whatever it is you're doing.
>
I thought you were going to mention the latter two; the question remains:
why not just do so in the first place, in the spirit of communication and
development?

None of the above stop a writeable check being useful imo: if the permission
isn't there as far as the kernel's concerned, there's no point trying the
rest of it. And as I said, errors still need to be checked (which would be
your "run it and see.")

>> > 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.
>
> Well, you're jumping in on a discussion about die implementations, so I
> assume you're fully aware of the relative merits and implementation
> details of all four solutions already. But if you're not... Try
> pointing out which the four solutions don't you recognise and
> understand. Explaining the implications of any one of them is
> non-trivial, so it's not something I'll do unnecessarily.
>
Don't bother: for some reason I don't feel very motivated by
this "conversation". I was discussing how to handle signals, btw, and
sharing something I learnt with others (which you clearly did not know
yourself.)

>> BTW people have implemented many correct solutions without
>> exceptions. You clearly still have much to learn from those who came
>> before you.
>
> ...Or maybe you really don't know the history of die implementations,
> because that's an insane claim to make.
<snip>
> So how, exactly, do I have something to learn from those before me?

Your statement that BASH's lack of exceptions means you cannot implement
correct solutions tells me you have much to learn technically, quite apart
from the social issues which have already been documented and discussed ad
nauseam.

> And why do you feel the need to comment when you don't know what the
> eselect die implementation is or how the changes to it introduced in
> Paludis make it better?
>
As stated, I was sharing knowledge and pointing out improvements and
possible solutions. You should try it some time (nice to see that you can
actually discuss, as above, but it's a shame it still takes 2 or 3 mails
before you will. Good luck with that.)


-- 
gentoo-dev@g.o mailing list