[pulseaudio-discuss] Accessing audio as root

[Colin Guthrie]

'Twas brillig, and Tanu Kaskinen at 02/01/10 05:59 did gyre and gimble:
> So that's how I see it should work. I'm not very confident when speaking
> about consolekit and boot/login processes, so I have to hope that the
> system I described isn't too different from how things work in reality.

I think I agree more or less, but with perhaps a few caveats/clarifications.

1. I think the "anybody" user is a valid concept. I'd personally call it
the "idle" or "inactive" user as homage to the active denomination in
consolekit already.

To run some practical tests, if you run:

[colin at jimmy ~]$ ck-list-sessions
Session1:
	unix-user = '603'
	realname = 'Colin Guthrie'
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ':0'
	x11-display-device = '/dev/tty7'
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2009-12-30T09:40:14.334448Z'
	login-session-id = '4294967295'

you can see that I am the "active" user currently.

If however I run the following and then switch to the login window on tty1:

[colin at jimmy ~]$ sleep 3; ck-list-sessions
Session1:
	unix-user = '603'
	realname = 'Colin Guthrie'
	seat = 'Seat1'
	session-type = ''
	active = FALSE
	x11-display = ':0'
	x11-display-device = '/dev/tty7'
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2009-12-30T09:40:14.334448Z'
	login-session-id = '4294967295'

Here we see that no user is currently "active". In this mode no user is
active on my system - i.e. it's "idle".


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)

5. Some special handling in the boot process will launch speakupd as the
idle user (I think this is appropriate - there should not (IMO) be a
central daemon for sepakupd - it should be launched when needed). I'm
not specifically sure if it is the "boot up" process per-se or the
"system becomes idle" case that really should be responsible for
starting speakupd... My gut feeling is that console-kit should be aware
of "idle" status and have a set of hooks that can be run when this
happens. These hooks could then be used to start speakupd as the idle
user). At this stage the idle user can now start talking about what is
going on with the boot.

6. X is launched and GDM (or equiv) is started, console-kit will now
realise there is an active session started for the gdm user and remove
the ACLs on the sound device. The idle user's speakupd can die as can
it's PA instance. GDM user will start it's own speakupd and PA process.

7. If at this stage the user logs in graphically then the same thing as
idle->gdm happens. The gdm user's PA and speakupd process dies and the
real user's one will kick in.

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.


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.

The concepts of "starting a service" are starting to erode these days
with more and more things being triggered from udev, so the general
migration to this approach (i.e. making speakupd "serviceless") seems to
be followed with the above suggestion too.

Also on a system shared by both blind and sighted users there does not
need to be any special support for detecting the current user and either
giving prompts or not. If speakupd is running it is running, it doesn't
need to be any cleverer than that. If I am correct with the above plan
all that really needs to be modified is consolekit.

Perhaps someone can have a bit of a think about this and see if it makes
sense and then perhaps discuss with the consolekit guys?

HTHs

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]