Considering ConsoleKit and GSettings/DConf

[Trevor Saunders]

Hi,

On Thu, Aug 12, 2010 at 04:28:06PM -0400, Bill Cox wrote:
> I'll just point out that in Vinux today, users have to edit three
> entirely separate sets of speech-dispatcher configuration files:
> /etc/speech-dispatcher controls the instance of speech-dispatcher used
> with speakup.  /var/lib/gdm/.speech-dispatcher controls GDM's copy of
> speech-dispatcher at the login window.  And users control their own
> Gnome instance with ~/.speech-dispatcher.

yes, as I've said before AddModule needs to go away, then this problem will too.
Personally I'd just run one system wide daemon in my book that's the point of
system services, everyone can use them.

> On the Vinux lists, we often get three posts from each new user as
> they try and get voxin to work with each of these systems, and it
> confuses the heck out of them!  We're strongly considering writing a
> simple python GUI app that lives on the desktop simply for the purpose
> of installing and configuring voxin in all three locations.
> 
> So, I empathise with users who prefer the simplicity of global
> pulseaudio and global speech-dipsatcher.  It's easy to configure, and
> more reliable.  I feel like we haven't come up with the right solution
> to the security issues of concern.

I think the session people are calling them issues when that's not really a fair
description.  There claim as I understand it is that using an audio group as has
been done is broken.  Its not *broken* its just that the system they want has a
different way of doing things.  The audio group system says users in this group
are trusted to do as they wish with audio period, this allows them to do things
that may be undesirable but that's not broken, its just how the system works.  I
believe that this arangement is fine in most situations, however there are
certainly situations in which it isn't an acceptible arrangement.

> For example, rather than running speech-dispatcher and pulseaudio as
> user, why not have both check permissions of the client now and then?
> Both systems are perfectly capable of handling multiple users in
> parallel, and running in user mode seems like a hack.  When things go
> wrong, typically the user has every right to the sound card, but some
> idle process has locked it up.  As a system-wide process, PA can mix
> sound from both legal users, and the idle process has no negative
> impact, and in fact sometimes positive, such as when users on the
> console want to hear notifications in Gnome.  If the screen has been
> locked, the rights manager should let PA and SD know that applications
> in the Gnome session have lost rights to the sound card, and cork
> them.  In the meantime, users on the consoles should be free to
> continue without worrying about the gnome session.  I suspect the
> reason for PulseAudio is that it required less work on their part to
> simply run as a user process, and let the system deal with
> permissions.  So, is all this pain about laziness?

I'm not quiet sure what you want here.  how would you check permissions of a
socket/ particularly how do you authenticate users?

Trev

> 
> Bill