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

[Ciaran McCreesh <ciaran.mccreesh@blueyonder.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 4889 bytes --]

On Sun, 11 Nov 2007 09:43:49 +0000
Steve Long <slong@rathaus.eclipse.co.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.

> Use of ((EUID)) is also quicker.

Quicker than what? 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.

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.

> Whatever. Requiring root for certain tasks has a long history:

On the kernel side.

> 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.

> >> 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.

> > 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.

> 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. So, the things you should have
known before you jumped in on a discussion about die implementations:

The original 'die' wasn't 'die'. It was a prefix alias.

The prefix alias had all kinds of issues, which were documented by
agriffis in his proposal for 'die'. This is mostly the same 'die' you
see in Portage and Pkgcore these days.

That die function has a long list of conditions it can't handle
correctly. When developing eclectic (which became eselect), I needed
something better because every module call to die would be under one
of those conditions. That was the original signal-die implementation,
which worked for what it needed to do at the time. (It also introduced
stack traces, which made their way into Portage.)

Unfortunately, although it would die reliably, because of various bash
implementation quirks, it would sometimes drop the friendly messages
and merely show a 'Killed' message. The version currently included in
Paludis is a refined version of the eselect implementation that doesn't
have the message dropping problem. Hence why I suggested copying the
changes for eselect.

And there are *still* issues with the newer signalling solutions due to
the limitations of Unix signals. Fortunately, any code that could
possibly trigger any of those limitations is illegal in ebuilds (but
not in eselect modules); unfortunately, people do it by accident anyway.

So how, exactly, do I have something to learn from those before me? 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?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]