Is it possible to run the Rhasspy docker image as a non-root user? I tried adding --user=1000:1000 (my user) to the command suggested in https://rhasspy.readthedocs.io/en/latest/installation/, but that seemed to break the container – the web server never started.
If you add the user to the dockergroup (group allowing to run docker containers), then you should be able to run it
Sorry, I wasn’t clear. I’m not worried about having to use ‘sudo’ to run the container. What I’m trying to avoid is having the process inside the container running as ‘root’, since that’s a security vulnerabiity.
The idea of a container is to have an enclosed environment. So the process inside cannot access anything outside of it without you explicitately allowing it. Maybe take a look at this:
Long story short: No, you don’t have to and you shouldn’t.
Yes, you can if you’re not accessing /dev/snd from inside. For some reason this won’t work (for me). So if you can get audio externally via gstreamer or something it works fine with --user.
@synesthesiam I did a little more troubleshooting, and it appears that if the rhasspy directory inside .config and its subdirectories don’t exist, running the docker container will create them owned by root, and then error out when it tries to access them as a non-root user. See the log below.
chowning the rhasspy directory and then rerunning the docker container solves the problem, but maybe worth making the process that creates those directories respect the ‘–user’ flag?
Starting up...
Using virtual environment at /usr/lib/rhasspy/.venv
DEBUG:rhasspysupervisor:Namespace(debug=True, docker_compose='', local_mqtt_port=12183, profile='en', supervisord_conf='supervisord.conf', system_profiles=None, user_profiles=PosixPath('/profiles'))
DEBUG:rhasspysupervisor:Loading profile en (user=/profiles, system=None)
DEBUG:rhasspyprofile.profile:Loading /usr/lib/rhasspy/rhasspy-profile/rhasspyprofile/profiles/en/profile.json
DEBUG:rhasspyprofile.profile:Loading /profiles/en/profile.json
Traceback (most recent call last):
File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/usr/lib/rhasspy/rhasspy-supervisor/rhasspysupervisor/__main__.py", line 99, in <module>
main()
File "/usr/lib/rhasspy/rhasspy-supervisor/rhasspysupervisor/__main__.py", line 76, in main
supervisord_conf_path.parent.mkdir(parents=True, exist_ok=True)
File "/usr/lib/python3.7/pathlib.py", line 1258, in mkdir
self._accessor.mkdir(self, mode)
PermissionError: [Errno 13] Permission denied: '/profiles/en'
@no_one Aren’t we punching a pretty big hole in that isolation by binding /profiles to the host file-system?
I don’t have that much experience with docker, but I’m not reading your link as saying that we don’t have to worry about processes in containers having root. For example, it concludes “Docker containers are, by default, quite secure; especially if you run your processes as non-privileged users inside the container.”
If there was a particular section of the article you were thinking of, could you point me to it?
So… as far as i know, Files in a mounted directory can only be accessed from inside the container as ReadWrite ONLY. You can specify different access privileges by e.g. docker run -v volume-name:/path/in/container:ro my/image with ro = read only.
However rhasspy needs to write files in the directory to be able to save the sentences or settings via the UI.
Furthermore you can limit the access to devices aswell as stated here: https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
This part. I personally heven’t tried it yet with rhasspy but you can give it a shot i guess.
Depening on how secure you want to be, processes in a contianer should not run as root if not needed.
Following principle of least privilege
1 Like
This is out of my control as far as I can tell. If the (parent) directories don’t exist, Docker seems to create them before executing Rhasspy as the specified user. I create the sub-directories inside the Rhasspy process as the current user.
If it’s bound to a directory where nothing else is stored (e.g., ~/.config/rhasspy/profiles), I don’t see the problem. Assuming no bugs in Docker itself, there should be no way for Rhasspy to modify files outside of this directory.
I’d like to, but I’ve had issues accessing /dev/snd without it. Maybe this has changed since I last checked?
Probably not, and if root is needed then so be it. But in general it is better to narrow the attack surface in any way possible
@Jacobb You can see how I have did it at https://github.com/poulsp/Psp-docker-Rhasspy.git and /dev/snd is no problem if you in the Dockerfile insert a usermod -a -G audio ${USER}
I use pi as user with UID and GID 1000. Same as me on my desktop.
1 Like