Hi, Sorry for the long email. TL;DR: festival --server (now with festival.socket/festival.service running automatically, listening on localhost only and with a systemd DynamicUser) opens a shell on the computer. Are we still happy? On 11 Jan 2026 at 11:12:31, Samuel Thibault wrote: > Carles Pina i Estany, le dim. 11 janv. 2026 07:21:52 +0100, a ecrit: > > In other words, I didn't know if festival server was an optimization > > but meant to be used by a single user or built to be used by multiple > > users. Happy that is for multiple users. > > De facto, already now if some user starts it, it'll be available for > other users on the tcp ports. Before today I had one concern about systemd running festival --server: As a user, when I install a web server (or other servers), I expect that the package will run a service that will open a port. I also expect that the default configuration is safe / secure (to a certain extend, at least). In other words: if I install Apache, I am not surprised that it will open a port and I expect that it might have a "welcome page" or something. Or a mail server will open a port and at least will not allow spammers to relay via my host. When I install a speech synthesizer: I don't expect that it will open a TCP port. Ok, the festival.socket is binding it on localhost only... but it might bit of a surprise. I also was concerned that I'm not familiar with what "festival --server" can do (I never used it integrated into speech-dispatcher, etc.) A few days ago, Sergio Oller contacted me to point out https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495286 . It's a bug from 2008 that says that in Debian lenny there was an init.d script for festival, but not in Debian etch. The init.d script was running, I understand, festival --server as the root user. And festival allows and still does in Debian trixie to run commands as the user that launched festival. More details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466146 How to run commands: https://bugs.gentoo.org/170477 I've confirmed it in a Debian trixie (disabling the festival.socket/service so I can run it as my user easier and find the /tmp file easier): carles@pinux:~$ festival --server server Sat Jan 17 07:28:56 2026 : Festival server started on port 1314 client(1) Sat Jan 17 07:28:59 2026 : accepted from localhost In another terminal: carles@pinux:~$ telnet localhost 1314 Trying ::1... Connection failed: S’ha refusat la connexió Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. (system "whoami > /tmp/festival-whoami2.txt") LP nil ft_StUfF_keyOK Then: carles@pinux:~$ cat /tmp/festival-whoami2.txt carles carles@pinux:~$ So, with all of this, I see that the situation after enabling festival.service/festival.socket: -It binds only to localhost -It's running as DynamicUser=yes Let's assume that only local users can take advantage of this. I see that a localhost user might try doing things on the machine but instead of the user's account it would be using the account that DynamicUser created by systemd. Is this a risk somehow? Is it something undesired? Could this help a malicious localhost user bypass some kind of security system? Also, I've been trying to create an HTML/JavaScript such as visiting a website it would send some data to localhost:1314. I haven't been able to do it on Firefox due to CORS and default safety measures. I managed with the "links" browser though. It connects to localhost 1314 and send the data that I want (I haven't managed to run the system LISP command but this is another discussion). All of this to point out: -festival --server is opening a remote shell (bound to localhost) -Are we still happy with the festival.socket/festival.service that we added? I only see that a local user can do things to the machine as the Dynamic user. I don't see how a user could visit a site with Firefox and then make the site connect to localhost:1314 but I am not a security expert. If it's not a problem and we decide that it's all good: ok! If it's a problem, in the short term: should we have a debconf question asking if the festival.socket/festival.service should be enabled? (the pros and cons) Cheers, PS: if I take a few days to answer: usually I do Debian stuff a few earlish mornings every week, depending on our baby's naps and sleeping :-) so I might not be able to follow up the discussion until Wednesday or Friday if it needs some time to answer. Or evenings depending on other family life things... -- Carles Pina i Estany https://carles.pina.cat | carles@pina.cat | cpina@debian.org
Attachment:
signature.asc
Description: PGP signature