Desktop Entry Spec : RootRequired entry

[Behdad Esfahbod]

On Sun, 28 Aug 2005, 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.

His proposal does not directly talk about what implementations
should do with the key, the key is only offering information
which is not available otherwise.  An implementation decides
whether to hide the entries or not, and according to his
suggested implementation, a user that has the root password is
identified by USER_IS_ADMIN, and so gets the entries in the menu.
If the administrator decides that the users do not have the root
password, there's really no point in showing them all these
entries...

behdad


> 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.
>
> -- dobey
>
>
> On Mon, 2005-08-29 at 02:34 +0200, Manu Cornet wrote:
> >
> > Hello !
> >
> > We had this subject discussed a few weeks ago, but as it gets more
> > precise, here's a short rationale and a patch (attached) for the
> > desktop-entry-spec.
> >
> > ##############################   Purpose   #############################
> >
> > The purpose is to hide, in the menus, programs that require elevated
> > privileges from non admin users, therefore reducing application clutter.
> >   A side effect would be to allow some distribution maintainers not to
> > manually prepend, for example, "gksudo" to the "Exec" value for these
> > entries.
> >
> > ###########################   Specification   ##########################
> >
> > The new key is RootRequired=yes|no|optional. It basically specifies
> > whether the program needs elevated privileges ; if "optional", the
> > program needs the privileges to fulfill all of its capabilities, but can
> > still be run and provide useful information if it hasn't.
> >
> > ###############   Possible implementation and rationale   ##############
> >
> > Now, apart from the spec, here's the most probable interpretation of
> > this. A boolean environment variable (USER_IS_ADMIN) could be set, each
> > distribution using its preferred way (for example, Ubuntu has an "admin"
> > group) to set it. Then the values of RootRequired would be used as follows :
> >
> > * "yes" : if USER_IS_ADMIN == 1, display the entry in the menus and use
> > elevated privileges (eg prepend "gksudo" to the Exec value). Otherwise,
> > hide the entry from the menus.
> >
> > * "no" : do nothing (do not hide the entry, do not modify the Exec value).
> >
> > * "optional" : do not hide the entry. If USER_IS_ADMIN == 1, use
> > elevated privileges ; otherwise, don't.
> >
> > * If USER_IS_ADMIN is not set or the RootRequired key doesn't exist in
> > the entry, assume the value is "no".
> >
> >
> > Doing this will allow the following :
> >
> > 1) Non-admin users don't see all these programs for which they don't
> > have the authorization anyway.
> >
> > 2) Elevated privileges are automatically used when needed.
> >
> > 3) Some programs, for example package management tools, can be run
> > without elevated privileges (eg list installed packages, search for a
> > particular package), but still need them for more control (eg actually
> > install new packages). By using the "optional" value, non-admin users
> > can still perform non-admin actions, while admin users can use the full
> > capabilities of the program.
> >
> >
> > That's it :o) The attached patch adds the RootRequired key to the
> > desktop-entry-spec. Can it be committed ?
>
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
>

--behdad
http://behdad.org/