Dbus atconsole policy

[Matthew Garrett]

Hi,
 
I've recently uploaded a dbus that has a slightly modified atconsole 
policy.

What is the atconsole policy?
-----------------------------

dbus allows certain services to be restricted. The most obvious example 
would be to limit which users can own certain services, but it can also 
be used to restrict which users can pass messages to certain services. 
This can be done by user, group or whether the user is at the system 
console.

How is it currently implemented?
--------------------------------

The default setup in dbus is to check whether there is a lockfile 
containing the user's username. This is generated at login by 
pam_console on Fedora and Red Hat systems.

How is this broken?
-------------------

Many users may be logged in at the console, especially if user switching 
is being used. All these users should be able to perform tasks such as 
putting the machine to sleep or changing the wireless setup (assuming 
that local policy is to allow users to do so), but only when they are 
the currently active user. An idle user in the background should not be 
able to suspend a machine that has an active user at the console.

What has changed?
-----------------

My patch to dbus means that dbus checks which virtual terminal is 
currently in use, and checks whether the user sending the message is 
logged in at that virtual terminal. If so, the message is permitted. If 
not, it is rejected.

Why are you telling us this?
----------------------------

In order for this to work, lockfiles must be generated for every user 
that logs in at the console. I've written a small PAM module 
(libpam-foreground) that will do this. On login, it will create 
/var/run/console/username:vtnumber. On logout, this will automatically 
be removed.

Adding this to /etc/pam.d/common-session would make things work out of 
the box, but common-session is used for both interactive and 
non-interactive sessions. I can't think of any especially good reason 
why this would be a problem, but what do others feel? The alternative at 
the moment is to add it to login, su and all the display managers.

Once this is done, I'll look at making sure that our HAL can suspend and 
hibernate the machine. Once that's worked out, gnome-power-manager 
should just do the right thing.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org