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
