running speech-dispatcher as non-root using setuid on XO and accompanying security issues
jim.simmons at walgreens.com
Fri Jul 18 16:53:54 EDT 2008
The point I was trying to make was that the Sugar API itself could have
removed the burden of setting these options from the developer. An
Activity, with just one line of code, could have set his speech client
to the default values. An Activity could also, using the API, find out
what the default values are without having to look at speechd.conf. Or
the Sugar Activity base class could automatically start up a speech
client and give the Activity developer simple methods to use it in his
application, or even automatically speech enable any Activity so that
for instance the contents of the control with the focus could be spoken,
or whatever it is that screen readers for the blind do. I understood
that the Sugar developers wanted to provide text to speech support to
all Activities, even those written before TTS was available. To do that
you would have to change the Sugar base classes, etc. anyway.
I don't see it as having redundant configuration. I see it as having
one configuration specifically tailored for what Sugar needs to do and
to be and another which is for all practical purposes completely ignored.
Just one man's opinion.
Hemant Goyal wrote:
> Thanks all for your inputs :)
> I managed to make speech-dispatcher as non-root using /tmp/speechd.pid
> and relocating the log files that were being written to
> /home/olpc/.speechd/. Since I started speech-dispatcher through the
> user olpc the log files need to be in a ~/ of olpc.
> I have some experience using speech-dispatcher and it seems to me
> that the XO really doesn't need to run speech-dispatcher any
> differently than any other computer does (other than getting rid
> of unnecessary dependencies of course). My understanding of what
> you want to do is that you want your contro,l panel to change the
> default settings in speechd.conf and restart speech-dispatcher so
> that all Activities that use speech will have these new default
> values to work with.
> In addition to what you have suggested, we want that a user be able to
> select speech synthesis settings in sugar-control-panel, and that
> those settings transparently get applied to all other client
> connections without the knowledge of the developer in the background
> when a connection is established.
> To my mind doing this (if I understand you correctly) is like
> burning down your house to cook a pig. Speech-dispatcher lets you
> override pretty much anything in speechd.conf. Since that is
> true, isn't the real problem how to give Sugar Activities a way to
> get these values set up for them using some data store maintained
> by your control panel? The data store doesn't have to be
> speechd.conf. It could be any file that can be updated by your
> control panel and read by other Activities. The Sugar API could
> have a method that takes the speechd client as a parameter and
> applies all the system-wide defaults that you are maintaining to
> it. After that the Activity could make changes on its own and
> save the values as meta information or whatever.
> Right, we did consider this approach but :
> 1. maintaining 2 copies of a similar configuration was not an
> elegant design option
> 2. we do not want the developer to make any effort whatsoever when
> they connect with speech-dispatcher to read/write/get and apply
> these settings every time they connect to speechd. In short this
> will lead to redundancy or replication of the code throughout
> activities, which will just be getting the settings and then
> applying them for their client connection.
> On the other hand, with the present approach of modifying speechd.conf
> the activity developer will not be required to write code to read
> these settings from the datastore and apply them for his/her own
> connection with speechd, instead the sugar defaults will be read and
> applied by speech-dispatcher themselves.
> Please let me know in case I have misinterpreted the point made by you.
> In any case, speechd does not have to run with dangerous
> permissions and Sugar Activities should get the benefit of your
> control panel with minimal work.
> Right, I have fixed this in my RPM package. I will soon be releasing
> the newest RPM which wont have any additional dependencies and which
> can be started by olpc user on the laptop.
> Thanks again for all the inputs.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel