Normal users who are not allowed to execute admin programs should not have the admin tools included in their menus, nor get update-notifier messages in the notification area of the panel.


It can be confusing if they try to access these functions and then they are not able to do what they believed.

Use cases

  1. Martin is the local administrator of his home machine and wants to have easy access to the administrative programs in the Gnome menu.
  2. Annett also uses this home machine, but is not allowed to change the system configuration. She does not want to see stuff that is not useful for her.
  3. Mathias is not a full admin, but he was granted sudo access to time-admin, since he needs the company laptop for travelling.


We need to detect whether the user has the privilege to execute a particular command as a particular user.

It was discussed to add an option to sudo itself that tells whether the user can execute a particular command. However, this would either entail information disclosure even on servers (where it matters), or cluttering log files and the administrator's email with failed sudo attempts.

Therefore a compromise was chosen that works for use cases 1 and 2, breaks use case 3, and still behaves sanely for upgrades from Debian and Warty: an administrative menu entry is shown if the user is in the 'admin' group or this group does not exist at all.


Desktop files

Additional fields can be added to the desktop files of applications which require nonstandard privileges:

X-KDE-SubstituteUID = true
X-KDE-Username = foo

These fields are already defined for KDE .desktop files, so we should just use them instead of introducing new names. X-KDE-Username defaults to root and usually does not need to be stated.


gnome-menus need to check the additional fields in the desktop file. A desktop file is hidden IFF:

  • group admin exists

  • the user is not in admin

  • X-KDE-SubstituteUID == true


update-notifier needs to hide the icon under the same conditions as stated above.

Data preservation and migration

No configuration files are changed by this spec.

Outstanding issues

  • In some cases users would want to have an ability to run a priviledged programm while running an account that does not have sudo configured. Usually this would be done using sudo. Maybe, if the user cann't run a command, it should be moved to a separate menu and if it is run from that menu it would ask for root pasword, while also allowing to enter username/password of another user that has sudo configured for a particular command. The password must be checked before checking the ability to run a particular command, for security reasons.
  • This works only with maintained .desktop files. Relevant (KDE) Issues for permission management beyond .desktop files are


HideAdminToolsToUsers (last edited 2008-08-06 16:17:54 by localhost)