Features/UsermodeMigration

Usermode Migration

Summary

All granting of privileged operations to ordinary users should be handled by centrally-managed system policy. Usermode/userhelper should be fully replaced by polkit in the future.

Owner

• Name: Harald Hoyer
• Email: harald@redhat.com

• Name: Kay Sievers
• Email: kay@redhat.com

Current status

• Targeted release: Fedora 18
• Last updated: 2012-04-03
• Percentage of completion: 20%

Detailed Description

The usermode/userhelper program is a setuid-root wrapper around a couple of tools, to provide superuser privileges to ordinary users. It’s policy is controlled by text files in /etc.

Most system policy today is controlled by polkit, a well-established, fine-grained, possible network-transparent infrastructure to manage privileged operations by ordinary users. Polkit can be used by privileged process to decide if it should execute privileged operations on behalf of the requesting user. Polkit also provides a setuid-root helper program called pkexec, its callbacks to ask for authorizations are well-integrated into shell and graphical environments.

Benefit to Fedora

• centrally managed policy, network-transparency possible
• polkit auth can distinguish between multiple sessions: e.g. untrusted user reboot request reboot only allowed when only a single user session runs
• intercepting tools in sbin/ with tools in bin/ is considered bad practice; fewer dependencies on $PATH ordering

Scope

• document how to convert consolehelper to polkit:
  • python: put pkexec in the wrapper shell
  • C tools: re-exec with pkexec in C code
  • C tools: move original to /usr/lib/<pkg>/<tool>, and wrap /usr/bin/<tool> with a pkexec shell (ugly!)
• open tracker bug and file bugs against all individual packages
• convert all packages, where it makes sense to use polkit, to pkexec
• for the rest, drop usermode and recommend to use pkexec like sudo

How to convert

A fast and easy way to convert a former consolehelper program is the use of pkexec.

As an example, we convert system-config-date to PolicyKit:

# ls -l /usr/bin/system-config-date
lrwxrwxrwx 1 root root 13  5. Feb 02:34 /usr/bin/system-config-date -> consolehelper

# rm /usr/bin/system-config-date
# cat /etc/security/console.apps/system-config-date
. config-util
PROGRAM=/usr/share/system-config-date/system-config-date.py
SESSION=true

Ok, running /usr/bin/system-config-date would have executed /usr/share/system-config-date/system-config-date.py, so we create /usr/bin/system-config-date like the following:

# cat /usr/bin/system-config-date
#!/bin/sh
exec /usr/bin/pkexec /usr/share/system-config-date/system-config-date.py

This will not export the DISPLAY variable, so we have to add a policy file, although starting a GUI as root is not encouraged. The important part is: <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>

# cat /usr/share/polkit-1/actions/org.fedoraproject.config.date.policy
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>

 <vendor>System Config Date</vendor>
 <vendor_url>http://fedorahosted.org/system-config-date</vendor_url>

 <action id="org.fedoraproject.config.date.pkexec.run">
    <description>Run System Config Date</description>
    <message>Authentication is required to run system-config-date</message>
    <icon_name>system-config-date</icon_name>
    <defaults>
     <allow_any>no</allow_any>
     <allow_inactive>no</allow_inactive>
     <allow_active>auth_self_keep</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/share/system-config-date/system-config-date.py</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
 </action>
</policyconfig>

How To Test

Make sure, you can call all the tools, which used to use usermode and be asked the appropriate password.

User Experience

anaconda
audit-viewer
authconfig-gtk
backintime
beesu
bootconf-gui
chkrootkit
driftnet
drobo-utils-gui
eclipse-oprofile
ejabberd
fwfstab
galternatives
gnome-system-log
gsmartcontrol
hddtemp
kdenetwork-kppp
kismet
liveusb-creator
lshw-gui
mock
mtr-gtk
netgo
nmap-frontend
ntfs-config
policycoreutils-gui
preupgrade
pure-ftpd
qtparted
revisor-cli
rhn-setup
rhn-setup-gnome
sabayon
setools-gui
setuptool
smart-gui
subscription-manager-gnome
synaptic
system-config-audit
system-config-bind
system-config-boot
system-config-date
system-config-httpd
system-config-kdump
system-config-keyboard
system-config-language
system-config-lvm
system-config-nfs
system-config-rootpassword
system-config-users
system-switch-displaymanager
system-switch-java
system-switch-mail
system-switch-mail-gnome
tuned
vpnc-consoleuser
wifi-radar
wlassistant
xawtv
yumex
zyx-liveinstaller

Contingency Plan

Even, if we cannot drop usermode, the changes in the packages do not have to be reverted.

Comments and Discussion

• See Talk:Features/UsermodeMigration