github-starred/firejail

Fork 0

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

[GH-ISSUE #3426] Feature request: Allow bind in non-root mode #2152

New issue

Closed

opened 2026-05-05 08:49:44 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 08:49:44 -06:00

Owner

Originally created by @howryu on GitHub (May 21, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3426

It seems that currently firejail only allows --bind under root user. Is this design for security concern? Is it possible to add support for non root user case? Probably need some sanitize in source/target directory e.g. source directory must be owned by current user, target directory should place under home directory.

Originally created by @howryu on GitHub (May 21, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3426 It seems that currently firejail only allows --bind under root user. Is this design for security concern? Is it possible to add support for non root user case? Probably need some sanitize in source/target directory e.g. source directory must be owned by current user, target directory should place under home directory.

gitea-mirror

2026-05-05 08:49:44 -06:00

closed this issue
added the
duplicate
label

gitea-mirror commented

2026-05-05 08:49:46 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 21, 2020):

Is this design for security concern?

Yes, consider --bind=~/evil.sudoers,/etc/sudoers

Is it possible to add support for non root user case?

I think it is.

Closing as duplicated of #459 (that's realy old 🥴)

@rusty-snake commented on GitHub (May 21, 2020): > Is this design for security concern? Yes, consider `--bind=~/evil.sudoers,/etc/sudoers` > Is it possible to add support for non root user case? I think it is. --- Closing as duplicated of #459 (that's realy old :woozy_face:)

gitea-mirror commented

2026-05-05 08:49:47 -06:00

Author

Owner

@howryu commented on GitHub (May 21, 2020):

@rusty-snake So is there plan to support binding in non-root case? Or how difficult it is to support that? Is sanitizing source/target directory's privilege good enough?
My use case is that I had a subdirectory under /opt, e.g. /opt/foo/bar(bar is owned by non-root user who will start the firejail). I want to access bar directory inside jail without exposing directory tree of /opt (so --private-opt is not an option here). I am also looking at --private= option (to mount /opt/foo/bar to the home directory), however I have multiple nested directory need to be accessed. so --private= is not viable either. :( Closet solution I can think of is mount bind multiple directory to the home directory in the jail.

@howryu commented on GitHub (May 21, 2020): @rusty-snake So is there plan to support binding in non-root case? Or how difficult it is to support that? Is sanitizing source/target directory's privilege good enough? My use case is that I had a subdirectory under `/opt`, e.g. `/opt/foo/bar`(bar is owned by non-root user who will start the firejail). I want to access `bar` directory inside jail without exposing directory tree of `/opt` (so `--private-opt` is not an option here). I am also looking at `--private=` option (to mount `/opt/foo/bar` to the home directory), however I have multiple nested directory need to be accessed. so `--private=` is not viable either. :( Closet solution I can think of is mount bind multiple directory to the home directory in the jail.

gitea-mirror commented

2026-05-05 08:49:48 -06:00

Author

Owner

@ghost commented on GitHub (May 21, 2020):

So is there plan to support binding in non-root case?

There are no 'hidden' (non-public) plans in the firejail project. As long as there aren't any PR's specifically implementing this feature, it's safe to assume no plans to do so.

Or how difficult it is to support that? Is sanitizing source/target directory's privilege good enough?

Hard to answer. At the very minimum a fair amount of C programming skills/experience and insight to the Linux kernel security infrastructure I'd say.

About your use case. If you can mount --bind /opt/foo/bar /home/howryu/bar prior to starting firejail, it would be easy to control access to that location from inside the sandbox by way of all the regular firejail options (including private-opt none). Is there anything special to your use case that warrants the need for a bind mount inside the sandbox?

@ghost commented on GitHub (May 21, 2020): > So is there plan to support binding in non-root case? There are no 'hidden' (non-public) plans in the firejail project. As long as there aren't any PR's specifically implementing this feature, it's safe to assume **no plans to do so**. > Or how difficult it is to support that? Is sanitizing source/target directory's privilege good enough? Hard to answer. At the very minimum a fair amount of C programming skills/experience and insight to the Linux kernel security infrastructure I'd say. About your use case. If you can `mount --bind /opt/foo/bar /home/howryu/bar` _prior_ to starting firejail, it would be easy to control access to that location from inside the sandbox by way of all the regular firejail options (including private-opt none). Is there anything special to your use case that warrants the need for a bind mount _inside_ the sandbox?

gitea-mirror commented

2026-05-05 08:49:50 -06:00

Author

Owner

@howryu commented on GitHub (May 21, 2020):

@glitsj16 It seems that mount requires root privilege? I don't want to switch to root to do the mount.

@howryu commented on GitHub (May 21, 2020): @glitsj16 It seems that `mount` requires root privilege? I don't want to switch to root to do the mount.

gitea-mirror commented

2026-05-05 08:49:51 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 22, 2020):

You could also do this at start by a systemd.service or fstab (https://serverfault.com/questions/613179/how-do-i-do-mount-bind-in-etc-fstab/613184#613184).

@rusty-snake commented on GitHub (May 22, 2020): You could also do this at start by a systemd.service or fstab (https://serverfault.com/questions/613179/how-do-i-do-mount-bind-in-etc-fstab/613184#613184).

gitea-mirror referenced this issue

2026-05-05 10:15:18 -06:00

[PR #2152] [CLOSED] Improve profile handling #4185

gitea-mirror referenced this issue

2026-05-05 10:15:19 -06:00

[PR #2156] [MERGED] Improve include handling #4186

gitea-mirror referenced this issue

2026-05-05 10:15:24 -06:00

[PR #2157] [CLOSED] Fix 2155 - Add user-profiles configuration option. #4188