speechd-up debian install question

[Michael Whapples]

I agree so much with the general feeling. PulseAudio is really more bother 
than its worth and probably creates more issues than it solves. Are the 
security issues really a problem? Proper user groups should sort out many of 
the issues, do not let users who have remote access have sound card access 
if its really an issue.

Michael Whapples
----- Original Message ----- 
From: "Bill Cox" <waywardgeek at gmail.com>
To: "Speakup is a screen review system for Linux." <speakup at braille.uwo.ca>
Sent: Tuesday, November 08, 2011 11:51 PM
Subject: Fwd: speechd-up debian install question


I agree with you 100%.  The sound card needs to be as rock solid as
the display.  Not only that, but:

- We're doing *extra* work to make our system's sound less stable
- Is allowing other people logged into my machine to play sound
*really* a security issue?  I mean... are they kidding?  Maybe the
mic, but a pure output device?

Honestly, I think what happed is it was easier to write certain parts
of Pulse Audio in user mode, and to save the author a little work, the
majority of blind Linux users suffer.

Now, the entire community of sound developers can go ahead and
continue claiming there's some hypothetical benefit to this mess, but
in my experience, you do work to fix stuff to make it better, not
worse.

Bill

On Mon, Nov 7, 2011 at 9:46 AM, Janina Sajka <janina at rednote.net> wrote:
> Samuel Thibault writes:
>> Bill Cox, le Sun 30 Oct 2011 10:49:30 -0400, a écrit :
>> > Rob mentioned that it would be better if speechd-up would run as a
>> > non-privileged user, rather than root. I agree. Is there a simple
>> > way to get the speakup_soft module to be readable by a non-root user?
>>
>> Simply chgrp/chmod /dev/softsynth. It could be useful to add to thesou
>> documentation the udev rules to do that automatically.
>>
>> > I guess my preference would be readable by all users, but of course
>> > that let's anyone logged into the machine follow what's going on on
>> > the console. Ideally only the user logged into the console could
>> > access /dev/synth. Does anyone know if this is doable?
>>
>> Such things are already done for sound & such, so it most probably is,
>> probably in udev.
>>
> I have a very hard time accepting the Linux sound environment as an
> example of good practice, especially with respect to permissions.
>
> For example, pulseaudio preventing root from playing audio is security 
> gone wacko. It's also not a11y friendly, i.e. "give root password for 
> system maintenance."
>
> To my mind the proper model is the video display. Audio per;missions
> should work the same way as video device permissions. On my machines,
> /dev/vcs* are all chown root and chmod 660. What's wrong with that? And,
> for the heck of it, why should /dev/ttsynth be more restricted?
>
> Janina
>
>
>> Samuel
>> _______________________________________________
>> Speakup mailing list
>> Speakup at braille.uwo.ca
>> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>
> --
>
> Janina Sajka, Phone: +1.443.300.2200
> sip:janina at asterisk.rednote.net
>
> Chair, Open Accessibility janina at a11y.org
> Linux Foundation http://a11y.org
>
> Chair, Protocols & Formats
> Web Accessibility Initiative http://www.w3.org/wai/pf
> World Wide Web Consortium (W3C)
>
> _______________________________________________
> Speakup mailing list
> Speakup at braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>



__________ Information from ESET NOD32 Antivirus, version of virus signature database 6620 (20111111) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com