github-starred/firejail

Fork 0

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

y #2014

New issue

Closed

opened 2026-05-05 08:41:01 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 08:41:01 -06:00

Owner

Originally created by @jonleivent on GitHub (Feb 11, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3218

I have a user account with a homedir that is a grandchild of /home - like /home/x/y. If I start firejail --noprofile --whitelist=~/test (assuming ~/test exists) in /home/x/y for user y, firejail issues the above warning, but doesn't exit. It starts the shell in / instead of /home/x/y. I get what looks like the same filesystem as outside the jail. All files in the /home tree are just as accessible as they were outside.

Originally created by @jonleivent on GitHub (Feb 11, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3218 I have a user account with a homedir that is a grandchild of /home - like /home/x/y. If I start `firejail --noprofile --whitelist=~/test` (assuming ~/test exists) in /home/x/y for user y, firejail issues the above warning, but doesn't exit. It starts the shell in / instead of /home/x/y. I get what looks like the same filesystem as outside the jail. All files in the /home tree are just as accessible as they were outside.

gitea-mirror closed this issue

2026-05-05 08:41:02 -06:00

gitea-mirror commented

2026-05-05 08:41:04 -06:00

Author

Owner

@smitsohu commented on GitHub (Feb 15, 2020):

Is FUSE, NFS, or an exotic filesystem, or a symbolic link part of the story?

@smitsohu commented on GitHub (Feb 15, 2020): Is FUSE, NFS, or an exotic filesystem, or a symbolic link part of the story?

gitea-mirror commented

2026-05-05 08:41:05 -06:00

Author

Owner

@jonleivent commented on GitHub (Feb 15, 2020):

Is f2fs exotic? It's a Samsung SSD, so f2fs seems like a perfect fit. Admittedly not as mundane as ext3|4.

Also, yes, FUSE is part of the story, as the reason for /home/x/y is that /home/x is a FUSE mount point for encrypted home dirs. Two reasons for doing it this way: it allows fuse mounting several associated home dirs, but not all, together . And avoids the problems with fuse failing to mount and having users accidentally overwrite the mount point (no user has /home/x directly as their home dir).

I did also try this with a sym link from /home/x to /home/y/x, with /home/x the user's home dir. Same issues.

@jonleivent commented on GitHub (Feb 15, 2020): Is f2fs exotic? It's a Samsung SSD, so f2fs seems like a perfect fit. Admittedly not as mundane as ext3|4. Also, yes, FUSE is part of the story, as the reason for /home/x/y is that /home/x is a FUSE mount point for encrypted home dirs. Two reasons for doing it this way: it allows fuse mounting several associated home dirs, but not all, together . And avoids the problems with fuse failing to mount and having users accidentally overwrite the mount point (no user has /home/x directly as their home dir). I did also try this with a sym link from /home/x to /home/y/x, with /home/x the user's home dir. Same issues.

gitea-mirror commented

2026-05-05 08:41:07 -06:00

Author

Owner

@smitsohu commented on GitHub (Feb 18, 2020):

Warning: cannot find home directory

It means what it says. Firejail was looking for the home directory, probably somewhere in /home, but it was not able not find it. As the directory evidently exists, this seems to suggest a problem with permissions.

Is FUSE, NFS, or an exotic filesystem, or a symbolic link part of the story?

I asked because FUSE and a number of distributed file systems impose restrictions on the root user, which usually breaks Firejail. There should be no issue with f2fs, but the FUSE mounts are going to need an allow_root mount option.

Probably not relevant here, but if user home directory (more specifically, the directory referred to in /etc/passwd as user home directory) is outside of /home, there is indeed a very similar issue which was fixed in 0.9.62.

@smitsohu commented on GitHub (Feb 18, 2020): > Warning: cannot find home directory It means what it says. Firejail was looking for the home directory, probably somewhere in /home, but it was not able not find it. As the directory evidently exists, this seems to suggest a problem with permissions. > Is FUSE, NFS, or an exotic filesystem, or a symbolic link part of the story? I asked because FUSE and a number of distributed file systems impose restrictions on the root user, which usually breaks Firejail. There should be no issue with f2fs, but the FUSE mounts are going to need an `allow_root` mount option. Probably not relevant here, but if user home directory (more specifically, the directory referred to in /etc/passwd as user home directory) is _outside_ of /home, there is indeed a very similar issue which was fixed in 0.9.62.

gitea-mirror commented

2026-05-05 08:41:07 -06:00

Author

Owner

@jonleivent commented on GitHub (Feb 18, 2020):

Couldn't firejail get around this limitation by first trying to accomplish something as root, then if that fails, try again as the invoking user? In this case, the invoking user has no problem at all finding the home dir.

@jonleivent commented on GitHub (Feb 18, 2020): Couldn't firejail get around this limitation by first trying to accomplish something as root, then if that fails, try again as the invoking user? In this case, the invoking user has no problem at all finding the home dir.

gitea-mirror commented

2026-05-05 08:41:08 -06:00

Author

Owner

@smitsohu commented on GitHub (Feb 19, 2020):

Couldn't firejail get around this limitation by first trying to accomplish something as root, then if that fails, try again as the invoking user?

Maybe, but we would need to change our privilege management. Firejail would need to run as the user (all user id's), but keep CAP_SYS_ADMIN to do the mounts.

@smitsohu commented on GitHub (Feb 19, 2020): > Couldn't firejail get around this limitation by first trying to accomplish something as root, then if that fails, try again as the invoking user? Maybe, but we would need to change our privilege management. Firejail would need to run as the user (all user id's), but keep CAP_SYS_ADMIN to do the mounts.

gitea-mirror commented

2026-05-05 08:41:09 -06:00

Author

Owner

@jonleivent commented on GitHub (Feb 19, 2020):

Wouldn't be safer to do as much as possible as the user, and fall back on firejail's suid powers only when user permissions aren't sufficient? Then, if the system has unprivileged_userns turned on, most (all?) things would just work without even needing to be suid. I think those people that complain about firejail's attack surface would be less likely if it wasn't suid - they'd be to busy complaining to linux kernel developers about unprivileged_userns.

Anyway, this is now an academic exploration. I will have to workaround the fuse mount vs. firejail issues for now, somehow. Closing...

@jonleivent commented on GitHub (Feb 19, 2020): Wouldn't be safer to do as much as possible as the user, and fall back on firejail's suid powers only when user permissions aren't sufficient? Then, if the system has unprivileged_userns turned on, most (all?) things would just work without even needing to be suid. I think those people that complain about firejail's attack surface would be less likely if it wasn't suid - they'd be to busy complaining to linux kernel developers about unprivileged_userns. Anyway, this is now an academic exploration. I will have to workaround the fuse mount vs. firejail issues for now, somehow. Closing...

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#2014

No description provided.

Rows
Columns