[pulseaudio-discuss] Accessing audio as root
Lennart Poettering
lennart at poettering.net
Tue Jan 5 06:19:07 PST 2010
On Tue, 05.01.10 08:48, Bill Cox (waywardgeek at gmail.com) wrote:
>
> On Tue, Jan 5, 2010 at 8:01 AM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > I have discussed this with Kay now and he'd very much prefer to do
> > this with a proper "idle" session that some tool (maybe some wrapper
> > around the speakup daemon) registers in CK, instead of patching
> > udev-acl.
> >
> > That should allow us to do without CK and udev-acl patches and allows
> > non-a11y setups to stay unmodified.
>
> Just double checking that I understand correctly...
>
> I still need to modify speechd-up and espeakup to deal with the sound
> card rights coming and going, and that if I do just this alone, I
> should be able to get speakup working whenever a user is logged in.
> This discussion of the "idle" session is simply about how to generate
> sound for login prompts on the console, correct? This would in theory
> allow a gdm or speakup session to own an instance of PA that hangs
> around rather than exiting, without locking access to the sound card
> as it does now if the speakup driver doesn't exit (and it doesn't).
Yes, the speakup daemons need to be modified so that they can be run
as a normal user instead of root, and then can deal with devices (both
audio and those special speakup kernnel devices) being assigned and
taken away from them. We'd then run one of those daemons in each
session and have one pseudo-session that owns the console as long as
nobody is logged in on it. That way speakup would become very similar
to orca and live in a nicely contained environment that closely mimics
the gdm user pseudo-session that gdm maintains.
In a simple list:
1) fix the speakup daemons so that they dont need root and can deal
with devices being assigned to them and going away.
2) write some udev rules that make the speakup special devices ACL
managed the same way as audio devices already are. (i.e. just set
ACL_MANAGE=1 for them, it's a one-liner)
3) write a little wrapper for the speakup daemons that sets up a
pseudo-session in ck that owns the console and then runs the speakup
daemon in it.
done.
>
> I could be wrong, but today I don't think CK follows what happens on
> the console in Ubuntu Karmic. Anything I do there seems to have no
> effect on access rights. Does this mean we also need to modify the
> console login program to create a user session?
The whole point of ConsoleKit is to follow who's logged in. Are you
suggesting that if you login on the console ck-list-sessions does not
list that session? If that's the case your really should have a word
with the Ubuntu developers...
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the pulseaudio-discuss
mailing list