speechd-up

[Trevor Saunders]

HI,

I think there may have been some miscommunication here.

I'd like to start by what talking about what spechd-up actually does,
namely it reads messages requesting text be synthesized in from a
file, and passes those requests on to speech-dispatcher.  Now, in the
most common use case those messages are in a file in /dev/ that i
being written to by the kernel.  HOwever, that isn't the only possible
or reasonable use.  For this common use a udev rule and dropping
privilages / chrooting after opening the file should allowspeechd-up
to work in the current world with very little modification, and after
start up aproximately zero permissions.

> 
> We also understand that some temporary solutions are necessary.  But we
> want to clearly identify what is a temporary hack and what is the
> desired final solution.  We can not afford following dead end roads.
> Long term accessibility must rely on main stream development, not
> obscure, specifically tailored hacks.

whatever the actually issues may or may not be with speakup, I think
providing the interface that speechd-up is can't be much of a bad
thing, or get in the way much.
Personally I don't have much of an issue with speechd-up running as
root, but I don't think it needs to run or possibly even start as
root. Speechd-up may need to be root for one reason which is to open a
file in /dev there are two things we can easily do to change / lessen
this.
1. drop root with setuid after calling open() on /dev/foo
2. use udev to change the permissions of  /dev/foo such that onyl a
certain group can access it.
3. since there is no reason not to speechd-up could also chroot after
reading its configuration file, so if we make the file speechd-up
reads commands rom be /dev/some-dir/foo then speechd-up can chroot to
/dev/some-dir just after reading its config file, so it will only have
access to that one file, just to increase security even more.

> We really welcome if anyone wants to work on Speakup and speechd-up in
> the direction which Hynek roughly described.  We may discuss the details
> of it, but it approximately is the only way to go and keep up with the
> current development, which we can hardly stop and there actually is not
> a reason for doing that.  It brings some additional complexity, but it
> addresses real issues.  We can not blindly insist on running all
> services as root just because it is simple.

I would agree, a lot of things have no reason to run as root and
probably shouldn't.  However, I think we've been unclear about this,
its not neccessary to use console kit and the "wonders" of session
integration to do this, we can do most of it with unix groups and
permissions, like what me and WIlliam have said is easily possible
with speechd-up.  If you look at the opentts daemon there is a working
example of this, we support a system wide mode in which the server ran
as its own user, and I believe ospeakup did something similar.  THis
has a little bit of an issue in that comsole kit may have to be told
that even though the speech user isn't sitting at the console it
always has permission to use the sound system, but this seems like the
basic sort of feature that is / should be in console kit.

> If we can agree on this approach, we'll be happy to host such project on
> the Free(b)soft site.  If we can not agree on that, we somewhat
> understand the motivation, but we simply don't want to be connected with
> it, because we believe it is fundamentally wrong.  We also don't want
> restrict the future development of Speech Dispatcher by the need to
> comply with such design.

I think the only requirements anyone has for speech dispatcher is that
it support a system wide mode, but this clearly doesn't neccessitate
that it run as root.

> Hope this was said clearly and pragmatically enough and it doesn't
> offend anyone.  We highly respect what was achieved by the Speakup
> project, but the development goes on and we can not live in seclusion.

I think the speakup developers are activly interested in removing the
technical issues with merging speakup in to the main line kernel.
However, I I believe some people may also have some misconceptions
about its integration into standard distributions.  William said
Debian has a package, infact in the next release it will ship in the
standard kernel package.

I agree clean designs are important, however I think we have to
remember we are trying to write software that is useful, and for
software to be useful, it has to solve actual problems in a way that
users can use.

Trev

> Best regards, Tomas
> 
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd