Desktop Entry Spec : RootRequired entry

[Waldo Bastian]

I think the idea in general a good idea, in fact KDE already uses a KDE 
specific keys for .desktop files to indicate that an application requires 
root access and already has the possibility to supress such applications from 
the menu.

Having a common key in the .desktop file for this sounds like progress to me 
and I'm all for it.

What I would like to see clearified is whether, in case of "RootRequired=Yes", 
the menu system should do whatever is needed to run the program as root, or 
whether that is the responsibility of the application itself. In KDE the menu 
system typically calls kdesu to run the application as root when it indicates 
that it requires root, but there are also cases where an application is 
started with normal user privileges but which will require the root password 
later on.

So I think something is needed that covers the following options:

1) start normally, no root required
2) start as root, root required
3) start normally, root required (e.g. gnome-terminal -e su)
4) ask whether to start as root, root not required (optional)
5) start normally, root may be required later on for some actions (optional)

I don't care too much about 4) and 5)

Cheers,
Waldo

On Tuesday 30 August 2005 00:50, Manu Cornet wrote:
> 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
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050902/8242a520/attachment.pgp