From: "Michael Whapples" <mwhapples@aim.com>
To: "Speakup is a screen review system for Linux." <speakup@braille.uwo.ca>
Subject: Re: speechd-up debian install question
Date: Fri, 11 Nov 2011 11:31:51 -0000 [thread overview]
Message-ID: <FE733E34C40F453CAF5F1173BE5FE6F4@Mikelaptop> (raw)
In-Reply-To: <CAOLP8p7DsHTk1yeVkfCXMaNcQxLTSNKZhEy9sv30Bu=WmCMwbQ@mail.gmail.com>
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@gmail.com>
To: "Speakup is a screen review system for Linux." <speakup@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@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@braille.uwo.ca
>> http://speech.braille.uwo.ca/mailman/listinfo/speakup
>
> --
>
> Janina Sajka, Phone: +1.443.300.2200
> sip:janina@asterisk.rednote.net
>
> Chair, Open Accessibility janina@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@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
prev parent reply other threads:[~ UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
Jude DaShiell
` covici
` Christopher Moore
` William Hubbs
` Samuel Thibault
` Bill Cox
` Samuel Thibault
` Bill Cox
` Janina Sajka
` Fwd: " Bill Cox
` Chris Brannon
` Michael Whapples [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FE733E34C40F453CAF5F1173BE5FE6F4@Mikelaptop \
--to=mwhapples@aim.com \
--cc=speakup@braille.uwo.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).