HideAdminToolsToUsers

Differences between revisions 2 and 3
⇤ ← Revision 2 as of 2005-11-03 15:46:01 →
Size: 3461
Editor: 254_220_103_66-WIFI_HOTSPOTS
Comment: refinements
← Revision 3 as of 2005-11-09 23:04:55 → ⇥
Size: 3329
Editor: 209
Comment: we need our own patch, adapt spec to actual implementation
Deletions are marked like this. Additions are marked like this.
Line 30: Line 30:
It happens that the sudo CVS HEAD version enhanced the -l option to accept a command, and deliver in the exit code whether the user is allowed to execute that command. Thus it is not necessary to write any code on our own; the upstream patch just needs to be applied to the Ubuntu package. It happens that the sudo CVS HEAD version enhanced the -l option to accept a command, and deliver in the exit code whether the user is allowed to execute that command. However, CVS head is diverged too much from the current stable line, the patch does not apply at all. Thus we will implement our own small patch.
Line 32: Line 32:
With this patch, `sudo -l` ''command'' will exit with 0 if ''command'' can be executed by the user, and with 1 if not. We will add a '-t' option to sudo, so that `sudo -t` ''command'' will exit with 0 if ''command'' can be executed by the user, and with 1 if not.
Line 57: Line 57:
 * Apply the [http://www.courtesan.com/pipermail/sudo-cvs/2004-November/000119.html "check for command" patch] to sudo.
 * Ensure that `sudo -l` ''command'' never asks for the user's password. `sudo -l` respects the `listpw` option which is `true` by default, but it does not make sense when specifying a particular command, since the user can always just try to execute it with sudo.		  * `sudo -t` ''command'' should never ask for the user's password. This is no information leak, since the user can always just try to execute it straight away. [-t option implemented in 1.6.8p9-3ubuntu2]

Summary

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.

Rationale

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

Use cases

  • Martin is the local administrator of his home machine and wants to have easy access to the administrative programs in the Gnome menu.
  • 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.

  • However, Annett is in the lpadmin group, so she does want to see the Printer administration menu entry.

Design

Backend

We need a backend to detect whether the user has the privilege to execute a particular command as a particular user. Currently gnome-menus checks whether the user is in the admin group, but this breaks upgrades from Debian and Warty and does not respect local sudo configuration.

To avoid duplicating code and possibly introducing security holes, sudo itself should be used to answer this question.

It happens that the sudo CVS HEAD version enhanced the -l option to accept a command, and deliver in the exit code whether the user is allowed to execute that command. However, CVS head is diverged too much from the current stable line, the patch does not apply at all. Thus we will implement our own small patch.

We will add a '-t' option to sudo, so that sudo -t command will exit with 0 if command can be executed by the user, and with 1 if not.

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

gnome-menus need to check the additional fields in the desktop file and use sudo -l command in the .desktop file (or sudo -u X-KDE-Username value ... if given) to decide whether to display a particular .desktop file.

update-notifier

update-notifier needs to check whether the user can execute update-manager as root and hide the icon if not.

Implementation

Code

  • sudo -t command should never ask for the user's password. This is no information leak, since the user can always just try to execute it straight away. [-t option implemented in 1.6.8p9-3ubuntu2]

  • The changes to gnome-panel and update-notifier are straightforward and don't need to be spec'ed.

Data preservation and migration

No configuration files are changed by this spec.

Outstanding issues

BoF agenda and discussion

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