Passing file descriptors over DBUS

[Kay Sievers]

On Fri, Sep 09, 2005 at 09:20:57PM -0400, Havoc Pennington wrote:
> On Fri, 2005-09-09 at 07:48 -0400, Jim Gettys wrote:
> > 
> > Dunno.  One question this begs is where initialization for devices
> > belongs, or whether the desktop system should be responsible for this
> > activity.
> > 
> > I suspect some input devices will need calibration data loaded,
> > potentially firmware, and setting of operating modes....  Who should be
> > responsible for this?

Most of these devices can easily configured by hotplug, which today means
by udev rules. Or HAL, which is basically some sort of high-level hotplug
daemon, that can also do this job if udev can not know enough about the
device or a more complicated policy is needed. HAL can also support monitoring
and polling of devices which hotplug or udev never will.

> > Also, how do we get ownership set up properly for the device nodes?
> > If the device is not being used by X, it should be owned by the user;
> > X is currently running as root, but we'd like to fix this someday...

That is a job for pam_console(RH) or resmgr(SUSE). We are currently
thinking about a common replacement, that integrates better with udev
and HAL, but both current solutions should already be capable to solve such
a problem.

> David Zeuthen is probably a good person to ask. These kind of questions
> seem to argue for some kind of "device manager" feature though, we
> wouldn't want every process trying to use the device to have to contain
> this code.

For now "the device manager" is HAL and the related subsystem managers like
NetworkManager. They all run at the system level and when user policy
is needed, the desktop session talks through DBUS to the system level daemons
to request device changes. DBUS grants access to the system level daemons,
again by using the information pam_console/resmgr provides.

The most integrated example today is probably NetworkManager. Network
device configuration is only possible as root, but only the user knows what
interface wired/wireless is to use or to which accesspoint the machine should
associate.

This works by listening to kernel events for added/removed hardware with
udev, which sends these event after hotplug handling to HAL. HAL collects all
kind of subsystem specific information and sends a systemwide signal to all
interested listeners pointing to the new device object.
Now Networkmanager will take over the control of the new network interface,
merges available system network configuration and possibly applies its default
policy including dhcp-client and dns-server setup.

If a user is locally logged in, the desktop part of NetworkManager (applet)
is connected to the system level daemon and can provide policy or configuration
settings for the new device.
The desktop session can also instruct the daemon to reconfigure the interfaces
for joining a specific wireless network as an example.
Also a nice aspect, the passords for the wireless networks are stored in the
desktop session and are only available to this specific user.

This model is a nice separation of privileges and policy, allows a sane
default policy given at system level and is fully dynamic regarding to
hardware coming and going at any time during the systems uptime. I think a
similar approach can work for most other subsystems too.

Thanks,
Kay