[gentoo-dev] eselect_zenity: alpha eselect GUI

[gentoo-dev] eselect_zenity: alpha eselect GUI

[Donnie Berkholz]

Hey all,

I've been wanting a GUI for eselect lately, so tonight I hacked up the 
start of one called eselect_zenity [1]. It only works for the most 
trivial modules so far -- it has to parse eselect output, so special 
parsers need to be written for each type. eselect_zenity uses 
(surprise!) Zenity, a shell-scripting interface to GTK+.

I'd appreciate any patches you'd like to contribute to add functionality 
or fix bugs.

Thanks,
Donnie

1. http://dev.gentoo.org/~dberkholz/eselect_zenity/
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 8 Nov 2007 02:48:13 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> it has to parse eselect output

Part of the idea behind using standardised output functions was that
they could be replaced. The thought was, rather than trying to parse
console-centric output, you'd swap in a different implementation of the
output functions that fed to, say, ncurses or a GUI. Then you'd swap
the driver logic with something that calls multiple tasks in order
rather than merely doing one thing and then exiting (there's proper
environment isolation to allow that).

Might be easier to do things that way...

-- 
Ciaran McCreesh

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

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

[Donnie Berkholz]

On 10:54 Thu 08 Nov     , Ciaran McCreesh wrote:
> On Thu, 8 Nov 2007 02:48:13 -0800
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > it has to parse eselect output
> 
> Part of the idea behind using standardised output functions was that
> they could be replaced. The thought was, rather than trying to parse
> console-centric output, you'd swap in a different implementation of the
> output functions that fed to, say, ncurses or a GUI. Then you'd swap
> the driver logic with something that calls multiple tasks in order
> rather than merely doing one thing and then exiting (there's proper
> environment isolation to allow that).
> 
> Might be easier to do things that way...

I'll look into that. Got any good starting points (files, functions, 
docs)?

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 8 Nov 2007 04:07:42 -0800
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> I'll look into that. Got any good starting points (files, functions, 
> docs)?

Well, the whole of the eselect code is small enough that you should be
able to understand it pretty quickly... Then it'd just be a case of
making the main driver code a bit more flexible so that you can tell it
to swap in certain libraries.

Incidentally, I suspect it might be worth rewriting the core using some
of the techniques that we've discovered when writing Paludis. Things
like the fancier signalling die function and the cleaner module path
searching would be worth adopting. This would also be a good
opportunity to sneak in the more flexible driver that you probably
need. Might be worth speaking to whoever maintains Gentoo's branch of
eselect these days.

One thing in the code, by the way...

	if [[ ${UID} -ne 0 ]]; then

We've always told people not to do that. Capabilities required by
eselect modules should be tested by attempting to perform the action,
not by some arbitrary query done on UIDs or groups. Being UID 0 doesn't
mean you're allowed to do something, and not being UID 0 doesn't mean
you're not allowed to do something.

-- 
Ciaran McCreesh

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

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

[Steve Long]

Ciaran McCreesh wrote:

> if [[ ${UID} -ne 0 ]]; then
> 
> We've always told people not to do that. Capabilities required by
> eselect modules should be tested by attempting to perform the action,
> not by some arbitrary query done on UIDs or groups. Being UID 0 doesn't
> mean you're allowed to do something, and not being UID 0 doesn't mean
> you're not allowed to do something.
> 
I've always used EUID for the root check, eg:
if ((EUID)); then
        echo "You must be root to run this script" >&2
        exit 1
fi

This won't get round capabilities (so error status should still be checked
and the script bail with appropriate output, if it can't do something it's
supposed to) but it's sufficient for root privilege check, and is better
than UID which requires login as root. This doesn't, of course, deal with
non-root users, eg where users in group portage are allowed to carry out a
task.

You can check for that kind of thing with a writeable test, eg:
[[ -w $PORTDIR ]] || die 'Write access to portage dir required"
While none of this stops you from needing to check errors, it does make it
nicer for users, imo, if scripts check early on for broader permissions
where it's appropriate.

Wrt signalling die, the correct way for a script to terminate on signal is
something like this code, taken from a SIG_INT handler:
        trap INT
        kill -INT $$
This ensures the parent process is correctly notified. So IOW just kill self
with the appropriate signal, ensuring any traps are cleared.


-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

On Thu, 08 Nov 2007 18:22:48 +0000
Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > if [[ ${UID} -ne 0 ]]; then
> > 
> > We've always told people not to do that. Capabilities required by
> > eselect modules should be tested by attempting to perform the
> > action, not by some arbitrary query done on UIDs or groups. Being
> > UID 0 doesn't mean you're allowed to do something, and not being
> > UID 0 doesn't mean you're not allowed to do something.
> > 
> I've always used EUID for the root check, eg:

Which is just as bad.

> This won't get round capabilities (so error status should still be
> checked and the script bail with appropriate output, if it can't do
> something it's supposed to) but it's sufficient for root privilege
> check, and is better than UID which requires login as root. This
> doesn't, of course, deal with non-root users, eg where users in group
> portage are allowed to carry out a task.

Except you absolutely never should be checking for root. You should be
checking for capabilities.

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

> Wrt signalling die, the correct way for a script to terminate on
> signal is something like this code, taken from a SIG_INT handler:
>         trap INT
>         kill -INT $$
> This ensures the parent process is correctly notified. So IOW just
> kill self with the appropriate signal, ensuring any traps are cleared.

No it isn't. 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.

-- 
Ciaran McCreesh

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

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

[Steve Long]

Ciaran McCreesh wrote:
> On Thu, 08 Nov 2007 18:22:48 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> wrote:
>> > if [[ ${UID} -ne 0 ]]; then
>> > 
>> > We've always told people not to do that. Capabilities required by
>> > eselect modules should be tested by attempting to perform the
>> > action, not by some arbitrary query done on UIDs or groups. Being
>> > UID 0 doesn't mean you're allowed to do something, and not being
>> > UID 0 doesn't mean you're not allowed to do something.
>> > 
>> I've always used EUID for the root check, eg:
> 
> Which is just as bad.
>
No, it's better for the reason given: it doesn't require login as root. Use
of ((EUID)) is also quicker.

>> This won't get round capabilities (so error status should still be
>> checked and the script bail with appropriate output, if it can't do
>> something it's supposed to) but it's sufficient for root privilege
>> check, and is better than UID which requires login as root. This
>> doesn't, of course, deal with non-root users, eg where users in group
>> portage are allowed to carry out a task.
> 
> Except you absolutely never should be checking for root. You should be
> checking for capabilities.
>
Whatever. Requiring root for certain tasks has a long history: I didn't make
a value judgement, merely pointed out that there is a better method built
in to BASH. Further, group membership, while not as fine-grained as ACLs or
Linux Capabilities, is still a legitimate security mechanism. Just because
it was invented more than ten years ago, that doesn't make it useless.

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

<lhunath> igli: looks pretty reliable to me.
<igli> yer me too lhunath
<lhunath> lhunath@avaria ~ $ ll /tmp/a
<lhunath> -rw-rw-rw- 1 root root 0 2007-11-11 09:50 /tmp/a
<lhunath> lhunath@avaria ~ $ [[ -w /tmp/a ]]; echo $?
<lhunath> 1
<lhunath> lhunath@avaria ~ $ echo a > /tmp/a
<lhunath> -bash: /tmp/a: Permission denied
<lhunath> igli: that example is with grsec turned on making /tmp/a
unwritable.
<lhunath> so -w seems to take even grsec into account.

>> Wrt signalling die, the correct way for a script to terminate on
>> signal is something like this code, taken from a SIG_INT handler:
>>         trap INT
>>         kill -INT $$
>> This ensures the parent process is correctly notified. So IOW just
>> kill self with the appropriate signal, ensuring any traps are cleared.
> 
> No it isn't. 
Yes it is. I was talking about handling signals, which you appear to have
missed. It's not common knowledge so I thought I'd share it. (For those who
care about code, you can kill $$ from a subshell too, to signal the
_parent_ process.)

> 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. As such I
find your posts devoid of technical content, and negative. I'll leave it at
that; bear in mind I won't be responding unless you actually *present* and
discuss code solutions (beyond simply saying they "suck" or yet again
*yawn* marketing paludis while refusing to discuss /how/ or /why/ its
algorithms are better.)

BTW people have implemented many correct solutions without exceptions. You
clearly still have much to learn from those who came before you.


-- 
gentoo-dev@gentoo.org mailing list

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

[Christian Faulhammer]

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

Steve Long <slong@rathaus.eclipse.co.uk>:
> Ciaran McCreesh wrote:
> > Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> >> I've always used EUID for the root check, eg:
> > Which is just as bad.
> No, it's better for the reason given: it doesn't require login as
> root. Use of ((EUID)) is also quicker.

 Capabilites are the write access to the target you want to modify in
your eselect module:

test_for_root() {
	# checks if the user has rights to modify /usr/bin/
	[[ -w "${ROOT}/usr/bin" ]] || die -q "You need to be root!"
}

 That's how the the vim and Emacs eselect modules do it.  In my opinion
the best way to check for the rights needed.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

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

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

[Ciaran McCreesh]

[-- 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 --]

[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@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.
>
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@gentoo.org mailing list

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

[Fernando J. Pereda]

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

On Mon, Nov 12, 2007 at 09:13:32AM +0000, Steve Long wrote:
> > 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.)

And then you were shown your improvements are not. Why you had to jump
to the personal side, it is unknown to me, though.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

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

[Jan Kundrát]

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

Steve Long wrote:
>>> 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. 

They are flawed unless they are things like su/sudo/... . As a fine
example about why is this checking bad, see bug 186459 [1].

[1] https://bugs.gentoo.org/show_bug.cgi?id=186459

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Ciaran McCreesh]

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

On Mon, 12 Nov 2007 09:13:32 +0000
Steve Long <slong@rathaus.eclipse.co.uk> 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

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

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

[Dan]

Ciaran McCreesh wrote:
> On Mon, 12 Nov 2007 09:13:32 +0000
> Steve Long <slong@rathaus.eclipse.co.uk> 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.
>
>   
Hey Friends,

Mind taking this off list?  As much fun as it is to see two people run 
around in circles blindfolded with pointy sticks, It really doesn't 
belong here.

Thanks!
-- 
gentoo-dev@gentoo.org mailing list

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

[Jeroen Roovers]

On Tue, 13 Nov 2007 11:13:52 -0500
Dan <hydrogen@notyetimplemented.com> wrote:

> Mind taking this off list?  As much fun as it is to see two people
> run around in circles blindfolded with pointy sticks, It really
> doesn't belong here.

Would you mind not needlessly quoting ~9KB of text, next time?
Thanks! :)


Kind regards,
     JeR
-- 
gentoo-dev@gentoo.org mailing list

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

[Luis Francisco Araujo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Donnie Berkholz wrote:
> Hey all,
> 
> I've been wanting a GUI for eselect lately, so tonight I hacked up the 
> start of one called eselect_zenity [1]. It only works for the most 
> trivial modules so far -- it has to parse eselect output, so special 
> parsers need to be written for each type. eselect_zenity uses 
> (surprise!) Zenity, a shell-scripting interface to GTK+.
> 
> I'd appreciate any patches you'd like to contribute to add functionality 
> or fix bugs.
> 
> Thanks,
> Donnie
> 
> 1. http://dev.gentoo.org/~dberkholz/eselect_zenity/

Nice work, you should announce it too at the gentoo-guis ml.

:-)

Regards,

- --

Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHMyVKBCmRZan6aegRAq51AKDGK606Kms7RR06mR0uGD95NtEvRgCeL+Rk
UX948bV08q/nN5ryBVt8dlg=
=XVMM
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Doug Klima]

Donnie Berkholz wrote:
> Hey all,
>
> I've been wanting a GUI for eselect lately, so tonight I hacked up the 
> start of one called eselect_zenity [1]. It only works for the most 
> trivial modules so far -- it has to parse eselect output, so special 
> parsers need to be written for each type. eselect_zenity uses 
> (surprise!) Zenity, a shell-scripting interface to GTK+.
>
> I'd appreciate any patches you'd like to contribute to add functionality 
> or fix bugs.
>
> Thanks,
> Donnie
>
> 1. http://dev.gentoo.org/~dberkholz/eselect_zenity/
>   
This is something really good. I've been thinking that Gentoo could use
a few small GUI utilities. Items such as a notification-applet for GLSA
bits that affect your system. Similiar to Ubuntu's tool when there's
updates that need to be applied.

Additionally, I'd like to see all these utilities wrapped via PolicyKit
rather then using gksu and kdesu applications. PolicyKit is definitely
the way forward on designing custom, granular permissions and not
relying on root in a GUI environment.

While I haven't had much time to work on the bits, Gentopia does contain
PolicyKit (though the 0.7 snapshots that appear do have some issues and
you should stick to the 0.6 series). It's hopefully going to be the way
forward for Gentoo to use PolicyKit. As many may know, Fedora has made
this commitment and Ubuntu is starting to contribute more back and be
involved a bit more.
-- 
gentoo-dev@gentoo.org mailing list

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

[Markus Ullmann]

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

Doug Klima schrieb:
> While I haven't had much time to work on the bits, Gentopia does contain
> PolicyKit (though the 0.7 snapshots that appear do have some issues and
> you should stick to the 0.6 series). It's hopefully going to be the way
> forward for Gentoo to use PolicyKit. As many may know, Fedora has made
> this commitment and Ubuntu is starting to contribute more back and be
> involved a bit more.

The gui project peoples along with two contributors and upstream already
looked into that and at best we could use this notify feature for glsa.
Gentoo is just too different to sanely work with it for full updates.
Stuff like selecting useflags, outputting important changes, needed
configuration updates afterwards and some more issues are plain not
doable with packagekit.

Though there is some work going on to get an abstraction layer for all
three known package managers that work with the tree to make sure such a
notify can be done.

Greetz
Jokey


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

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

[Doug Klima]

Markus Ullmann wrote:
> Doug Klima schrieb:
>   
>> While I haven't had much time to work on the bits, Gentopia does contain
>> PolicyKit (though the 0.7 snapshots that appear do have some issues and
>> you should stick to the 0.6 series). It's hopefully going to be the way
>> forward for Gentoo to use PolicyKit. As many may know, Fedora has made
>> this commitment and Ubuntu is starting to contribute more back and be
>> involved a bit more.
>>     
>
> The gui project peoples along with two contributors and upstream already
> looked into that and at best we could use this notify feature for glsa.
> Gentoo is just too different to sanely work with it for full updates.
> Stuff like selecting useflags, outputting important changes, needed
> configuration updates afterwards and some more issues are plain not
> doable with packagekit.
>
> Though there is some work going on to get an abstraction layer for all
> three known package managers that work with the tree to make sure such a
> notify can be done.
>
> Greetz
> Jokey
>
>   
I only meant for notification purposes. Not for any updates or automatic
merges.
-- 
gentoo-dev@gentoo.org mailing list

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

[Donnie Berkholz]

On 20:22 Tue 13 Nov     , Markus Ullmann wrote:
> Doug Klima schrieb:
> > While I haven't had much time to work on the bits, Gentopia does contain
> > PolicyKit (though the 0.7 snapshots that appear do have some issues and
> > you should stick to the 0.6 series). It's hopefully going to be the way
> > forward for Gentoo to use PolicyKit. As many may know, Fedora has made
> > this commitment and Ubuntu is starting to contribute more back and be
> > involved a bit more.
> 
> The gui project peoples along with two contributors and upstream already
> looked into that and at best we could use this notify feature for glsa.
> Gentoo is just too different to sanely work with it for full updates.
> Stuff like selecting useflags, outputting important changes, needed
> configuration updates afterwards and some more issues are plain not
> doable with packagekit.

I'd like to talk in more detail about this with someone, but nobody on 
#gentoo-guis seemed to know why PackageKit wouldn't work for the simple 
(no USE flag changes) case. Should I try the -guis mailing list instead?

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

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

[Rémi Cardona]

Donnie Berkholz wrote:
> I'd like to talk in more detail about this with someone, but nobody on 
> #gentoo-guis seemed to know why PackageKit wouldn't work for the simple 
> (no USE flag changes) case. Should I try the -guis mailing list instead?

Looking at the current feature set of PackageKit, there's no reason we
couldn't add support for Gentoo.

However, PackageKit is really meant for binary distros, and some design
choices really rely on that. For instance, the PackageKit tray icon will
ping the backend for updates every 30 minutes or so (default value),
while this is perfectly fine for apt or yum where downloading the list
of available updates takes about 2 seconds (just to check the HTTP
headers to see if something has changed). Obviously, this can't be kept
as is for our case.

Also, PackageKit has its own conventions when it comes to packages being
available for one platform. Again, its model fits right with binary
distros and would require some major tweaking to fit our model, but I
don't think it's out of our reach.

Maybe one could start writing the search backend and the install/remove
backend. That would be a nice step in the right direction :)

Cheers,

Rémi
-- 
gentoo-dev@gentoo.org mailing list