This is a request for a security enhancement: ffmpeg should run as an unprivileged user with minimal access. For example, we could have an "ffmpeg" user and group which has access to the input file, a temporary output directory, and any necessary hardware transcoding features when that's supported.
Currently the ffmpeg process presents a large attack surface, and any vulnerability in ffmpeg automatically confers full peertube server database and filesystem access.
I remember seeing:
Which involve running ffmpeg with firejail to "sandbox" it using namespaces and seccomp-bpf.
If the shipped profile for ffmpeg with firejail works ootb in peertube too, the only thing needed is to be able to change the path used to the ffmpeg binary.
Paths to ffmpeg and ffprobe binaries can be set via Ffmpeg.setFfmpegPath(path) and Ffmpeg.setFfmpegPath(path) resp.
We already have a function to check available capabilities of the ffmpeg install at the server start. We could simply set the ffmpeg path there.
Or use the FFMPEG_PATH env variable
I'll add a note in the documentation about that last one then :)
I can confirm that using:
Environment=FFMPEG_PATH=/usr/local/bin/jail_ffmpeg
Environment=FFPROBE_PATH=/usr/local/bin/jail_ffprobe
In systemd works for using a custom binary.
When trying firejail I'm hitting others issues but that seems more related to the firejail config itself.
Just to bump about firejail and peertube.
There is an issue in firejail because peertube is installed with HOME on /var/www/peertube and firejail expect everything currently to be under /home.
There is a workaround here https://github.com/netblue30/firejail/issues/2259 but it's better to just reinstall peertube under /home instead of playing with symbolic links I think.
I haven't tested further but with /var/www/peertube and the issue I reported, I can definitely say that currently this can't work (unless using /home/peertube)
Most helpful comment
Or use the FFMPEG_PATH env variable