On Sun, 11 Nov 2007 09:43:49 +0000 Steve Long <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
