YaST/DBus Integration

From openSUSE

Yast as a DBus service

This documentation describes the experimental DBus support in Yast.

Warning: Experimental means that there might be bugs, it might even not work at all or there might be security problems. It is also still in development, that means that there might be incompatible changes in the future.

What is the advantage of this feature?

This feature will allow to

• use Yast from other applications
• set up role based access to the system management (for non-root users)

The current status

The current implementation runs only the lowest part of the Yast (SCR) as a DBus service. So the DBus service is a low level API to the system configuration. It allows to e.g. read/write configuration files, restart services, but it doesn't allow to e.g. install packages using libzypp or configure users (because these functions do not use SCR for accessing the system).

In the future it we should also export Yast namespaces via DBus so there will be also a high level API to the system management.

How use the DBus service

There are two mandatory steps to use the Dbus service in a Yast module.

1. Currently the DBus feature is disabled by default. To use it set variable

   Y2DBUS=1

   before starting a Yast module.
2. You have to enable PolicyKit actions performed by a particular Yast module to the relevant users. The PolicyKit action IDs have prefix "org.opensuse.yast.scr." followed by SCR method name (in the most cases "read", "write" or "execute") plus path to the agent (configuration).
   
   Example: read access to variable TIMEZONE in /etc/sysconfig/clock file has action ID org.opensuse.yast.scr.read.sysconfig.clock.timezone.
   To grant user joe read access to the variable add this rule to the PolicyKit configuration file /etc/PolicyKit/PolicyKit.conf (into config section):
   

<match user="joe">
  <match action="org.opensuse.yast.scr.read.sysconfig.clock.timezone">
      <return result="yes"/>
  </match>
</match>

PolicyKit supports POSIX Extended Regular Expressions in the action string, you can use e.g. .* metacharacters. If you want to grant read access to whole /etc/sysconfig/clock file use org.opensuse.yast.scr.read.sysconfig.clock..* string.

To grant write access use write instead of read in the string.

To grant unlimited access use org.opensuse.yast.scr..*.
WARNING: In this case the user will be equivalent to the root user! But it might be useful for testing or for getting action names, see the next paragraph.

Example

Here is an example of role based access to set timezone task for user joe. This task does not require too much actions.

1. Enable needed actions in /etc/PolicyKit/PolicyKit.conf for user joe, see YaST/DBus Integration/Polkit config/change timezone for list of the actions.

1. Execute Y2DBUS=1 /sbin/yast2 timezone as user joe. Now you can change the timezone. But you will not be allowed to change e.g. NTP settings there.

Global access

The SCR service supports also global access to functions since yast2-core-2.17.24 (openSUSE 11.1, SLES/SLED 11). There are extra actions which enable using the specified methods regardless the passed parameters. E.g. there is action org.opensuse.yast.scr.read which is equivalent to org.opensuse.yast.scr.read.*.

The advantage is that these actions can be simply used by polkit-auth command without need to edit the PolicyKit config file. And users can also obtain the privileges by themselves either by polkit-auth command or via the PolicyKit agent if they know the root password.

See /usr/share/PolicyKit/policy/org.opensuse.yast.scr.policy file for the complete list of the global actions.

How to get the action names for a system management task?

This is a hard task. Ideally there should be a list of needed actions for a particular task. Or the yast module itself should provide the list. Currently you have to watch the main yast log (/var/log/YaST2/y2log) for lines with <4> tag (e.g. use tail -f /var/log/YaST2/y2log | grep ' <4> ' command).

Because the SCR API is low level there will be probably performed many actions. Use regexps to decrease them to a reasonable amount. Warning: a regexp increases the access right, be sure that it cannot be misused, use regexps in read

Non-atomic change = possible problem

It is necessary to pay extra attention when defining the actions. If user has granted only subset of the needed rights the system might become broken. For example if the task T requires actions A and B, but the user is allowed to do only action A then the system might be misconfigured when the B action is denied after successful A.

Problem with logging

For non-root users Yast uses ~/.y2log file, while the DBus service is running as root and thus uses the system wide log file (/var/log/YaST2/y2log). When there is problem you have to check both logs. Both logs have to be also attached to bugzilla.novell.com if the problem happens under non-root user.

Future work

Parallel access

Parallel access is not supported. Starting more yast modules in parallel might have strange affect because all Yast instances will share the same SCR DBus server. There should be some locking or at least a warning should be displayed.

Performace

There is a performance hit because of the extra communication over DBus. The result is that the Yast modules which calls SCR:: function too often will run slower. In my test case the Yast firewall module was stared in about 25 seconds, without DBus it takes about 3 seconds.

The question is whether the slowdown is caused by the DBus communication or by extra data conversion between Yast and DBus data types. Moreover, the current implementation has not been optimized yet, there might be some possible improvements.

Problem with generic agents

There is a problem with defining actions for some SCR calls because some SCR agent are generic - e.g. they allow to execute arbitrary command in bash shell (.target.bash agent). To limit the amount of possible commands the command is part of the action name. The problem is that action name cannot contain some characters like colon (:), space. And the action string is limited to 255 characters.

It seems that the PolicyKit check should be also done in these generic agents, the check on the SCR level is not sufficient in this case.