[pulseaudio-discuss] Accessing audio as root

[Lennart Poettering]

On Sat, 02.01.10 14:08, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> Now lets think about permissions. Some folks have recently mentioned the
> "audio" group. This is a relic and should not be used or considered for
> controlling access to audio hardware. The real way forward is the
> interaction between udev and console kit applying ACLs for the
> appropriate users.
> 
> Now in this case we really need to define a user on the system who is
> "idle". Both udev and console-kit probably need to be aware of this
> concept and write the appropriate ACLs to the sound hardware for the
> "idle" user, removing them when a real user logs in (and in this case
> "gdm" should be considered a "real" user.
> 
> In this case the boot scenario (permissions wise) would be as follows:
> 1. Turn on (this will rarely change and I predict will remain the first
> step for many years :p)
> 
> 2. udev kicks in.
> 
> 3. system dbus starts
> 
> 4. consolekit starts and due to no active users instructs udev to write
> the idle user to the audio device node ACLs (I'm not 100% sure whether
> udev drives console-kit or the other way round, so someone more familiar
> than me with this can hopefully clarify)

udev-acl is a tiny piece of code that simply reads the ck database and
adjusts the device node ACLs accordingly. It is run whenever a device
is plugged in and the active session changes.

And support for such an idle user to udev-acl should be a job for 10
mins or so.

> 7b. Now if the user switches to tty1 (whether at gdm login screen or
> after logging in - the concept is the same), console-kit will notice the
> system has become idle and apply the appropriate ACLs, due the "idle
> hooks" mentioned in 5 above, speakupd/PA will be launched and the login
> prompt can be described audibly. Once logging in the user becomes active
> again, so the idle user is killed off as before and can hand over to the
> real user.

That means the tts daemon would have to run as the user on the
console. Which I think makes a lot of sense, just want explicitly
mention this.

> Thinking about it, I think that consolekit itself is really what should
> be responsible for starting speakupd (which will in turn start
> pulseaudio if appropriate). I think that some kind of "system becomes
> idle" and "user becomes active" hooks would provide the necessary
> framework into which speakupd could integrate.

Hmm, I am not sure if I agree that CK should be extended to be a
general session babysitting daemon. Console logins are broken
in many ways and particularly that there is no proper session daemon
for it, but I think we could work around that by putting some startup
code in /etc/profile.d/.

Also, the sepakup device access should be handled by udev-acl as
well. That would probably require non-trivial patching in the speakup
tts daemon though.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4