github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #3199] --private=subdir of encrypted dir does not work #2000

New issue

Closed

opened 2026-05-05 08:40:17 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

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

Owner

Originally created by @jonleivent on GitHub (Jan 31, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3199

In some cases, I would like to fuse mount an encrypted directory, then start a firejail with --private= a now unencrypted subdir of the mountpoint of that directory. The point is to use some app on data in that encrypted directory such that the app cannot accidentally leak some of that data out.

Right now when I try this I get the following error from firejail:

Error: invalid private directory

This is not some issue with firejail vs. permissions on the directory, because I can start a firejail shell without --private, and navigate into the directory in question. I'm using gocryptfs (ecryptfs is not in Debian Buster due to python2 and systemd logout issues). I can get around this by removing some of the protections of the fuse mounted directory using gocryptfs -allow_other option, but I'd rather not, and at least would like to understand why firejail doesn't work without -allow_other.

Versions: firejail 0.9.58-2. MX Debian buster 10.2. gocryptfs 1.6.1.

Originally created by @jonleivent on GitHub (Jan 31, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3199 In some cases, I would like to fuse mount an encrypted directory, then start a firejail with --private= a now unencrypted subdir of the mountpoint of that directory. The point is to use some app on data in that encrypted directory such that the app cannot accidentally leak some of that data out. Right now when I try this I get the following error from firejail: > Error: invalid private directory This is not some issue with firejail vs. permissions on the directory, because I can start a firejail shell without --private, and navigate into the directory in question. I'm using gocryptfs (ecryptfs is not in Debian Buster due to python2 and systemd logout issues). I can get around this by removing some of the protections of the fuse mounted directory using gocryptfs -allow_other option, but I'd rather not, and at least would like to understand why firejail doesn't work without -allow_other. Versions: firejail 0.9.58-2. MX Debian buster 10.2. gocryptfs 1.6.1.

gitea-mirror closed this issue

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

gitea-mirror commented

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

Author

Owner

@ghost commented on GitHub (Jan 31, 2020):

I can confirm this with firejail from git master and gocryptfs 1.7.1-1 on Arch Linux. Firejail uses realpath and stat functions, which apparently fail on FUSE filesystems. See the code in https://github.com/netblue30/firejail/blob/master/src/firejail/fs_home.c#L397 and https://github.com/netblue30/firejail/blob/master/src/firejail/fs.c#L74.

@ghost commented on GitHub (Jan 31, 2020): I can confirm this with firejail from git master and gocryptfs 1.7.1-1 on Arch Linux. Firejail uses realpath and stat functions, which apparently fail on FUSE filesystems. See the code in https://github.com/netblue30/firejail/blob/master/src/firejail/fs_home.c#L397 and https://github.com/netblue30/firejail/blob/master/src/firejail/fs.c#L74.

gitea-mirror commented

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

Author

Owner

@matu3ba commented on GitHub (Apr 9, 2020):

@glitsj16 tagging this with blocked by other program?

@matu3ba commented on GitHub (Apr 9, 2020): @glitsj16 tagging this with blocked by other program?

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Apr 9, 2020):

@jonleivent FUSE mounts without allow_other or allow_root can't be accessed by root (yes the user with UID=0). Try sudo ls /run/user/1000/gvfs: ls: cannot access '/run/user/1000/gvfs': Permission denied.

@rusty-snake commented on GitHub (Apr 9, 2020): @jonleivent FUSE mounts without allow_other or allow_root can't be accessed by root (yes the user with UID=0). Try `sudo ls /run/user/1000/gvfs`: `ls: cannot access '/run/user/1000/gvfs': Permission denied`.

gitea-mirror commented

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

Author

Owner

@jonleivent commented on GitHub (Apr 9, 2020):

My intention with using fuse mounts without allow_other or allow_root is to give the user more security. I'm using firejail on that user's apps to prevent any leakage of secure information from their encrypted store. I want to use both together - I don't want to trade off one type of security for the other.

I was initially under the impression that firejail, when run by a user, can perform individual actions either as that user (and handle the above fuse mounts) or root, whichever works. I guess what you are telling me is that this is not the case.

I have some workarounds in place for managing firejail's inability to deal directly with fuse mounts that don't have allow_other or allow_root. The main workaround is to have firejail use home dirs that are not themselves encrypted, but are read-only, and have encrypted fuse-mounted subdirs. This is working fairly well so far.

I don't mind if you close this issue.

@jonleivent commented on GitHub (Apr 9, 2020): My intention with using fuse mounts without allow_other or allow_root is to give the user more security. I'm using firejail on that user's apps to prevent any leakage of secure information from their encrypted store. I want to use both together - I don't want to trade off one type of security for the other. I was initially under the impression that firejail, when run by a user, can perform individual actions either as that user (and handle the above fuse mounts) or root, whichever works. I guess what you are telling me is that this is not the case. I have some workarounds in place for managing firejail's inability to deal directly with fuse mounts that don't have allow_other or allow_root. The main workaround is to have firejail use home dirs that are not themselves encrypted, but are read-only, and have encrypted fuse-mounted subdirs. This is working fairly well so far. I don't mind if you close this issue.

gitea-mirror referenced this issue

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

[PR #2000] [MERGED] Create tor-browser-* directories #4148

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2000

No description provided.

Rows
Columns