Festival Speech Synthesis System: - Speech Resource Pages

Every effort has been made to minimise the risk of unauthorised access through Festival and a number of levels of
security are provided. However with any program offering socket access, like httpd, sendmail or ftpd there is
a risk that unauthorised access is possible. I trust Festival's security enough to often run it on my own machine and
departmental servers, restricting access to within our department. Please read the information below before using the
Festival server so you understand the risks.
[ < ] [ > ] [ > ] [Top] [Contents] [Index] [ ? ]
28.3.1 Server access control
The following access control is available for Festival when running as a server. When the server starts it will usually
start by loading in various commands specific for the task it is to be used for. The following variables are used to
control access.
server_port
A number identifying the inet socket port. By default this is 1314. It may be changed as required.
server_log_file
If nil no logging takes place, if t logging is printed to standard out and if a file name log messages are
appended to that file. All connections and attempted connections are logged with a time stamp and the name
of the client. All commands sent from the client are also logged (output and data input is not logged).
server_deny_list
If non-nil it is used to identify which machines are not allowed access to the server. This is a list of regular
expressions. If the host name of the client matches any of the regexs in this list the client is denied access.
This overrides all other access methods. Remember that sometimes hosts are identified as numbers not as
names.
server_access_list
If this is non-nil only machines whose names match at least one of the regexs in this list may connect as
clients. Remember that sometimes hosts are identified as numbers not as names, so you should probably
exclude the IP number of machine as well as its name to be properly secure.
server_passwd
If this is non-nil, the client must send this passwd to the server followed by a newline before access is given.
This is required even if the machine is included in the access list. This is designed so servers for specific tasks
may be set up with reasonable security.
(set_server_safe_functions FUNCNAMELIST)
If called this can restrict which functions the client may call. This is the most restrictive form of access, and
thoroughly recommended. In this mode it would be normal to include only the specific functions the client can
execute (i.e. the function to set up output, and a tts function). For example a server could call the following at
set up time, thus restricting calls to only those that `festival_client' --ttw uses.
(set_server_safe_functions
'(tts_return_to_client tts_text tts_textall Parameter.set))
Its is strongly recommend that you run Festival in server mode as userid nobody to limit the access the process will
have, also running it in a chroot environment is more secure.
For example suppose we wish to allow access to all machines in the CSTR domain except for
holmes.cstr.ed.ac.uk and adam.cstr.ed.ac.uk. This may be done by the following two commands
(set! server_deny_list '("holmes\\.cstr\\.ed\\.ac\\.uk"
"adam\\.cstr\\.ed\\.ac\\.uk"))
(set! server_access_list '("[^\\.]*\\.cstr\\.ed\\.ac\\.uk"))
This is not complete though as when DNS is not working holmes and adam will still be able to access the server
(but if our DNS isn't working we probably have more serious problems). However the above is secure in that only
machines in the domain cstr.ed.ac.uk can access the server, though there may be ways to fix machines to
identify themselves as being in that domain even when they are not.