Re: Activation of Speech Dispatcher under squeeze
Hynek Hanke, le Fri 24 Sep 2010 11:42:47 +0200, a écrit :
> On 24.9.2010 02:11, Samuel Thibault wrote:
> >Root can output text to
> >ordinary users at will, nothing bars him from doing that either on the
> >linux console, or X11, etc. Why should audio be different?
>
> Are you speaking about the thing that he should be able
> to connect to other users sessions and do everything
> he likes here? I think it might be useful in some cases,
> but I think it is not (yet?) supported in ConsoleKit.
Then consolekit should be fixed before imposing itself.
> This is not so easy as just writing audio to roots default
> soundcard. The root would need to know which is the
> proper audio device for the target user, and that is being
> assigned dynamically in Pulse Audio, AFAIK.
This is not really a problem, in that it's also a problem for X displays
and connected users. Root is used to having to deal with that by hand
and he's fine with that.
> I don't think it is Speech Dispatcher's task to, for every
> user, query their current audio device setup, listen for
> fallbacks on sink changes in PA etc. This sounds difficult!
Sure, I never suggested that. But pulseaudio is now preventing the
very simple way of doing it: just let speech-dispatcher run as root and
accept any user tts. I'm fine with establishing better ways to prevent
e.g. somebody logged via ssh to output some tts. But I'm not fine with
just forbidding the simple way! (particularly since as you agreed it
can be useful for root to be able to cast some sound).
> I think it is much easier if Speech Dispatcher just uses
> what is available in the given session and not care about
> it too much.
For tackling with multi-seat, I agree. For the common single-seat,
that's complicated for not much.
> If there is a requirement to have the root user do things
> in this session, because he is a superuser, I think it's better
> to solve this outside Speech Dispatcher, by allowing him
> to become part of this session for a moment.
I agree that my concern with root power is not about speech-dispatcher
but pulseaudio.
> >>I think BrlTTY needs to have a better notion of users and sessions
> >>and then it will interconnect well with Pulse Audio, DBUS and the
> >>other desktop technologies.
> >>
> >How do you log in? Which user is supposed to provide the audio
> >feedback?
> >
>
> In discussions on the Pulse Audio mailing list was proposed
> a concept of an 'idle session'. This is a session that exists on the
> local computer in case no other user is currently claiming any
> active session there. I think this needs to be precised though.
Before imposing it, it sure needs to be precised, yes :)
> >>Speech Dispatcher is just an intermediate who can't do much about it.
> >>
> >Well, the issue is that we're here mixing unix users with physical
> >users. What we really want is to identify the real user, while
> >pulseaudio/dbus/brltty can only deal with unix users.
>
> To make it more precise, PulseAudio/DBus deals with sessions,
> not users. I still think this makes situation simpler, if we consider
> all the relations and consequences (as I've pointed one above with
> the audio sinks migration). Software components such as Speech
> Dispatcher simply don't have to care about all the complexities
> of various attributes of the user sessions, of security policies between
> them etc.
Sure. But it doesn't make the solution any simpler compared to the
current "root does it all" way we've been having up to now. So
pulseaudio/debus need to provide very good explanations and support
before being able to impose anything.
> >And another issue of course is that to actually be able to read the linux
> >console you
> >need to be root.
>
> Only if you directly open and own the /dev device. We know all
> the problems related with this. It would be much better to use
> HAL/udev for the access (I'm not very familiar with current state
> of hardware access technologies), and then if the policy is set properly,
> every user could see his own and BrlTTY would not need to run under
> root.
This is quite hairy. And you dropped my paragraph about having to revoke
rights from /dev/vcsa again after logout. This is _not_ implemented in
the kernel and needs to be first, else you get a security hole.
> >>GDM runs in its own session, so there is no problem. Speech Dispatcher
> >>gets started, when GDM tries to use it.
> >>
> >What about console screen login? We'll have to patch
> >login/agetty/mgetty/*tty, as well as kdm/xdm/...? It's really painful
> >that it has become an _obligation_ in nowaday's pulseaudio mind.
>
> These are already patched upstream to give feedback to ConsoleKit, AFAIK.
To give feedback, ok, but to start a screen reader??
> On the Speech Dispatcher mailing list, we are already working
> on the roadmap for Speech Dispatcher. Do you think it would make
> sense to join together with our developers and develop a broader
> roadmap, including BrlTTY and Speakup?
Well, what would make sense is pulseaudio and dbus to actually talk with
us before imposing anything without knowledge of our needs.
> Another thing is, we will get to talk about this on the AEGIS
> conference early next month, where we will get to speak with
> the Gnome accessibility developers about it.
Ideally there should be some pulseaudio/dbus people.
Samuel
Reply to: