On Mon, 12 Nov 2007 09:13:32 +0000
Steve Long <[EMAIL PROTECTED]> wrote:
> >> 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?Well, I was kind of wondering... Because it looked to me like you were implying that EUID is faster than UID. Which is clearly untrue... > > 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 ]]. ...which is exactly what we were discussing, as you know fine well. > > 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.) The existing check is completely wrong. You're presenting a less readable but marginally faster incorrect alternative in a place where a small constant performance factor gain is irrelevant. > >> 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. Then get them fixed. > >> 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. And there is no correct way to test whether those privileges are available using bash, which brings us back to my original point. > 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? Because I assume I'm dealing with an audience that more or less understands the topic at hand and doesn't need every single detail explicitly spelt out. > 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. Except that [[ -w ]] can return false negatives. > > 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.) Had you bothered to study any of the newer die implementations, you'd realise that I know exactly how all that works. > > 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 Not at all. If you think they can, it shows you don't know enough about Unix signal handling and obscure-but-sadly-common side cases. > quite apart from the social issues which have already been documented > and discussed ad nauseam. Repeating something over and over doesn't make it true. > > 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 don't know what the existing solution is or what the improved solution being proposed is, so how can you point out improvements? > You should try it some time Funnily enough, that's exactly what I did when I suggested moving from the original eselect implementation to the newer Paludis implementation. > (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.) Mmm, let's see. First email: suggested moving from the original eselect die to the newer Paludis die. More than enough information there for anyone involved in the discussion to understand and make the changes. Your reply: missing the point about signals, and getting it wrong, without understanding what the two different methods are. Second email: me giving you a convenient list of the die implementations that you should have studied before jumping in to begin with. Your reply: claiming that said convenient list isn't posting code, when in fact it's a list of bits of code that you should have read before offering 'suggestions' (translation: trying to show off when you don't actually know what's being discussed). Following up with a claim that people have implemented correct solutions, where you yourself neither post code nor state where such solutions exist. Third email: telling you even more explicitly the things you should have known before jumping in. Your reply: silly trolling repeating claims that people make when they realise they've made a fool of themselves and are trying to shift it into making me look bad. Nobody falls for that any more. -- Ciaran McCreesh
signature.asc
Description: PGP signature
