Desktop Entry Spec : RootRequired entry

[Manu Cornet]

Hi !

> I'm still not clear as to how the menu implementation is supposed to
> *know* whether or not the user has root access (either via sudo, or by
> knowing the actually root password.  Having some mechanism in place
> (which also needs to be defined) to set an env var such as USER_IS_ADMIN
> sounds awkward and messy to me.  Plus, it's not in-session changeable,
> and requires a session restart to take effect (granted, changing admin
> status doesn't generally happen often).  Personally, I think using env
> vars to do anything on a desktop level is the wrong approach.

Well, I'm not an experienced developper here, but I'm really willing to 
work hard in order to make this right. The problem is I'm only hearing 
"Wrong Way" messages, without anybody trying to lead me towards the 
right door :)

We (I didn't decide all this all by myself) have already thought of 
other solutions, none of which seemed better than this one. But if you 
have a better idea, I will sincerely be glad to discuss about it, and 
work on the code so that it can be implemented.

> In addition, how do we know which method to use: sudo, gksu, su, etc.?

Does that need to be written in the spec (I thought it would be part of 
the implementation part) ? How can this be distribution-independant, 
when, for instance, not all distributions use sudo ?

> Considering the problem I mentioned above, how does the implementation
> know whether or not to ask for root access in an 'optional' case where
> the user does indeed have root privileges. 

I suppose you're talking about cases where an admin user would want to 
run the program as non-admin (just to get info without changing it) for 
more security ? I don't think there can be an easy solution for that, 
except displaying two different menu entries (which seems of the 
question) or asking the user every time. I proposed that if the user 
does indeed have root privileges, root access should be provided (and 
password asked) in an "optional" case. And in the current situation, I 
don't think a user has the choice for this when running a program from 
the menus (has he ?). But then again, if you see a better option, I'll 
be glad to hear it.

> Note also that, in a case
> like sudo, a user may have privileges to run some applications as root,
> and not others.  There's no way to distinguish this ahead of time
> without parsing /etc/sudoers.

Right. That's why I have been discussing with the guys from sudo. There 
is a way to know (with the sudo command) whether a given user is 
authorized to run a given command. But this requires that the user 
inputs his password (which is out of the question when displaying 
menus). And this need for a password seems important to the guys from 
sudo, for security reasons (and I tend to believe them on this kind of 
matter). Duplicating the sudo code (with slight changes) to make a 
dedicated helper doesn't seem to be a very efficient way either.

> And I don't see the point of adding complexity to the spec for something
> cosmetic.  With proper menu editors -- as defined by the spec -- users
> should be able to remove items they don't want to see.

I don't think we're speaking about the same kind of users, here :) I'm 
working to make GNOME (and Linux in general) easier to use for most of 
the people, without giving up any of its stability. Asking to total 
beginners (I mean beginners as in "Hey, I don't get the difference 
between those two buttons on my mouse") to edit their own menus doesn't 
seem really realistic to me.

Imagine you just bought a new TV and you're surprised to see that dozens 
of debugging messages (none useful to you) still appear at the top of 
the screen. You call the hotline : will you be happy if they tell you 
"Oh yeah, we thought removing them was cosmetic stuff, but you can do it 
yourself, just open the rear panel, exchange condenser C124 and 
resistance B687, then weld tracks 685 and 431 together. We have included 
a special tool to do this in the package, you'll see, it's easy". ?

> I can see the usefulness of this addition for one thing only: the
> ability of the menu system to know when admin access is required, and
> provide a mechanism for the user to enter a sudo/su password when they
> run the app.

This wasn't the main purpose, but I agree it's an useful consequence as 
well.

Cheers,
Manu