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.
