[GH-ISSUE #2259] Whitelisting results in fs_private: Read-only file system

gitea-mirror commented

2026-05-05 08:10:31 -06:00

Owner

Originally created by @rhaamo on GitHub (Nov 13, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2259

Using firejail 0.9.56-1 (the .deb amd64 one from SFnet).

I want to jail ffmpeg and ffprobe for the user peertube which HOME directory is /var/www/peertube.
I created a ffprobe profile like that (diff from ffmpeg):

< # Firejail profile for ffmpeg
---
> # Firejail profile for ffprobe
6c6
< include /etc/firejail/ffmpeg.local
---
> include /etc/firejail/ffprobe.local
34c34
< private-bin ffmpeg
---
> private-bin ffprobe

And two wrappers:

cat /usr/local/bin/jail_ffprobe 
#!/bin/bash
/usr/bin/firejail -- /usr/bin/ffprobe "$@"

So I want ffprobe/ffmpeg to be able to transcode videos in /var/www/peertube/storage/videos and I've written the following profile:

read-write /var/www/peertube/storage/avatars
read-write /var/www/peertube/storage/logs
read-write /var/www/peertube/storage/cache
read-write /var/www/peertube/storage/cache/video-captions
read-write /var/www/peertube/storage/cache/previews
read-write /var/www/peertube/storage/torrents
read-write /var/www/peertube/storage/thumbnails
read-write /var/www/peertube/storage/videos
read-write /var/www/peertube/storage/captions
read-write /var/www/peertube/storage/previews

If I do /usr/local/bin/jail_ffprobe /var/www/peertube/storage/videos/somevideo.ext I get a No such file or directory (the file really exists), so I tried to whitelist that directory with:

whitelist /var/www/peertube/storage/videos

But now it results in:

/usr/local/bin/jail_ffprobe /var/www/peertube/storage/videos/somevideo.ext                                                
Error chown: fs_home.c:339 fs_private: Read-only file system
Error: proc 29346 cannot sync with peer: unexpected EOF
Peer 29347 unexpectedly exited with status 1

Whitelisting storage or the home itself results in the same error.

Any ideas how to get that working ?

Originally created by @rhaamo on GitHub (Nov 13, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/2259 Using firejail 0.9.56-1 (the .deb amd64 one from SFnet). I want to jail ffmpeg and ffprobe for the user ```peertube``` which HOME directory is ```/var/www/peertube```. I created a ffprobe profile like that (diff from ffmpeg): ```diff < # Firejail profile for ffmpeg --- > # Firejail profile for ffprobe 6c6 < include /etc/firejail/ffmpeg.local --- > include /etc/firejail/ffprobe.local 34c34 < private-bin ffmpeg --- > private-bin ffprobe ``` And two wrappers: ``` cat /usr/local/bin/jail_ffprobe #!/bin/bash /usr/bin/firejail -- /usr/bin/ffprobe "$@" ``` So I want ffprobe/ffmpeg to be able to transcode videos in ```/var/www/peertube/storage/videos``` and I've written the following profile: ``` read-write /var/www/peertube/storage/avatars read-write /var/www/peertube/storage/logs read-write /var/www/peertube/storage/cache read-write /var/www/peertube/storage/cache/video-captions read-write /var/www/peertube/storage/cache/previews read-write /var/www/peertube/storage/torrents read-write /var/www/peertube/storage/thumbnails read-write /var/www/peertube/storage/videos read-write /var/www/peertube/storage/captions read-write /var/www/peertube/storage/previews ``` If I do ```/usr/local/bin/jail_ffprobe /var/www/peertube/storage/videos/somevideo.ext``` I get a ```No such file or directory``` (the file really exists), so I tried to whitelist that directory with: ``` whitelist /var/www/peertube/storage/videos ``` But now it results in: ``` /usr/local/bin/jail_ffprobe /var/www/peertube/storage/videos/somevideo.ext Error chown: fs_home.c:339 fs_private: Read-only file system Error: proc 29346 cannot sync with peer: unexpected EOF Peer 29347 unexpectedly exited with status 1 ``` Whitelisting storage or the home itself results in the same error. Any ideas how to get that working ?

gitea-mirror

2026-05-05 08:10:31 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 08:10:33 -06:00

Author

Owner

@smitsohu commented on GitHub (Nov 13, 2018):

At this moment in time the support for home directories outside of /home is incomplete.

But I think it should be possible to work around the current limitations:

create a symbolic link in /home pointing to the users home directory /var/www/peertube
in /etc/passwd, provide this symbolic link as home directory of user peertube
start the sandbox with --writable-var option
expect problems when this user peertube runs firejail with --allusers, --overlay or --chroot options (just to say it, you're maybe not interested in this anyway)

@smitsohu commented on GitHub (Nov 13, 2018): At this moment in time the support for home directories outside of `/home` is incomplete. But I think it should be possible to work around the current limitations: - create a symbolic link in `/home` pointing to the users home directory `/var/www/peertube` - in `/etc/passwd`, provide this symbolic link as home directory of user peertube - start the sandbox with `--writable-var` option - expect problems when this user peertube runs firejail with `--allusers`, `--overlay` or `--chroot` options (just to say it, you're maybe not interested in this anyway)

gitea-mirror commented

2026-05-05 08:10:34 -06:00

Author

Owner

@smitsohu commented on GitHub (Nov 13, 2018):

and not to forget:

all file access should be via the symlink in /home
so you can do blacklist /var/www/peertube

It's really funky work around. We should probably just try to fix it 😄

@smitsohu commented on GitHub (Nov 13, 2018): and not to forget: - all file access should be via the symlink in `/home` - so you can do `blacklist /var/www/peertube` It's really funky work around. We should probably just try to fix it :smile:

gitea-mirror commented

2026-05-05 08:10:35 -06:00

Author

Owner

@rhaamo commented on GitHub (Nov 13, 2018):

Thanks !
I went somewhat in the same conclusion that the issue was because HOME was outside of /home :)

I will try the workaround in the next few days to see it if helps.

@rhaamo commented on GitHub (Nov 13, 2018): Thanks ! I went somewhat in the same conclusion that the issue was because HOME was outside of /home :) I will try the workaround in the next few days to see it if helps.

gitea-mirror commented

2026-05-05 08:10:36 -06:00

Author

Owner

@smitsohu commented on GitHub (Nov 26, 2018):

One problem are users who control the home directory path (i.e. have write permission on earlier elements of the pathname)... they could redirect us everywhere by means of symbolic links.

I think fixing this shouldn't be too hard if denying symbolic links in home directory paths is considered an acceptable limitation. In the special case where the entry in /etc/passwd references a link inside /home (as in the workaround above), everything would work as it does now. While not perfect, it would be probably good enough for almost all users.

Other/better ideas? @netblue30?

@smitsohu commented on GitHub (Nov 26, 2018): One problem are users who control the home directory path (i.e. have write permission on earlier elements of the pathname)... they could redirect us everywhere by means of symbolic links. I think fixing this shouldn't be too hard if denying symbolic links in home directory paths is considered an acceptable limitation. In the special case where the entry in /etc/passwd references a link inside /home (as in the workaround above), everything would work as it does now. While not perfect, it would be probably good enough for almost all users. Other/better ideas? @netblue30?

gitea-mirror commented

2026-05-05 08:10:38 -06:00

Author

Owner

@smitsohu commented on GitHub (Nov 26, 2018):

Regarding the implementation, the proposed fs_tmpfs function from #2276 could be called from fs_private if the home directory is outside /home. The other fs_private* functions would need to do something similar.

@smitsohu commented on GitHub (Nov 26, 2018): Regarding the implementation, the proposed `fs_tmpfs` function from #2276 could be called from `fs_private` if the home directory is outside /home. The other fs_private* functions would need to do something similar.

gitea-mirror commented

2026-05-05 08:10:39 -06:00

Author

Owner

@smitsohu commented on GitHub (Nov 29, 2018):

Maybe we can call realpath early on on user homedir and check, while denying symbolic links, once if that directory is owned by the user.... Then there would be no need to compromise regarding symlinked home directory paths. Also, a restriction that the home directory must be owned by the user looks quite natural.

@smitsohu commented on GitHub (Nov 29, 2018): Maybe we can call realpath early on on user homedir and check, while denying symbolic links, once if that directory is owned by the user.... Then there would be no need to compromise regarding symlinked home directory paths. Also, a restriction that the home directory must be owned by the user looks quite natural.

gitea-mirror commented

2026-05-05 08:10:40 -06:00

Author

Owner

@smitsohu commented on GitHub (Jul 25, 2019):

Should be fixed now in master.

@smitsohu commented on GitHub (Jul 25, 2019): Should be fixed now in master.

gitea-mirror referenced this issue

2026-05-05 10:11:54 -06:00

[PR #1512] [MERGED] Fix logging for servers #3999

Rows
Columns

[GH-ISSUE #2259] Whitelisting results in fs_private: Read-only file system #1512