Desktop Entry Spec : RootRequired entry

[Brian J. Tarricone]

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

On 8/29/2005 2:31 AM, Manu Cornet wrote:

> Rodney Dawes wrote:
>
>> This seems like the wrong way to go about this to me. There are some
>> things users SHOULD see in the menu AND that require elevated priveleges
>> to use. Changing the date/time, software update tools, file sharing with
>> samba, are just some examples.
> 
> I really can't see why these things SHOULD be seen in the menu for
> non-sudoers. If I don't have a sudo/root password, and I want to set the
> time & date, I click on the appropriate entry... And the only thing I
> can get to is gksudo's dialog awaiting for a password, which I don't
> know. That doesn't give me much of an information (not to mention it's
> quite frustrating), and in this case I'd better see this entry hidden
> from me, since I can't use it anyway.

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.

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

> As long as a program can actually provide me with some information
> without entering a sudo/root password (even though maybe I can't change
> everything I want, just visualize the settings), then its RootRequired
> value should be at least "optional", and the entry won't be hidden.

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

>> If your menus are overly cluttered, it might be better to think about
>> how some of these things can be consolidated, or reorganized, so that
>> the menus are not as cluttered. I don't think we should be putting
>> workarounds for usability/design issues within the specs.
> 
> The menus are already very well organized, especially the System menu
> with an Administration submenu. I just really don't see the point of
> letting non-admin users see all this admin stuff they can't use at all,
> even inside a submenu...

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

	-brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFDE00a6XyW6VEeAnsRArehAKDS80YSIJJluomFN0I0Nad0pdj6hQCdEZLn
IFVjGjhFOAyqI9V27wlBf3M=
=gs5i
-----END PGP SIGNATURE-----