[GH-ISSUE #2114] Hiding HOME with --whitelist: cannot open directory '.' #1432

New issue

Open

opened 2026-05-05 08:05:57 -06:00 by gitea-mirror · 16 comments

gitea-mirror commented 2026-05-05 08:05:57 -06:00

Owner

Copy link

Originally created by @onlyjob on GitHub (Sep 14, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2114

I'm trying to hide contents of HOME directory from jailed application using --whitelist option as described in #583:

firejail --whitelist=/home/user/tmp_ bash

However instead of empty home with tmp_ folder in it I get ls: cannot open directory '.': Permission denied when I try ls in user's home directory (ls tmp_ works):

$ firejail --noprofile --whitelist=$(readlink -f $HOME/tmp_) bash -c 'ls'
Parent pid 143110, child pid 143111
Child process initialized in 25.74 ms
ls: cannot open directory '.': Permission denied

Parent is shutting down, bye...

What is the recommended way to jail application in a fake user's home to hide certain locations that application have no business accessing?

firejail version 0.9.54

Thanks.

Originally created by @onlyjob on GitHub (Sep 14, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/2114 I'm trying to hide contents of HOME directory from jailed application using `--whitelist` option as described in #583: firejail --whitelist=/home/user/tmp_ bash However instead of empty home with `tmp_` folder in it I get `ls: cannot open directory '.': Permission denied` when I try `ls` in user's home directory (`ls tmp_` works): ~~~~ $ firejail --noprofile --whitelist=$(readlink -f $HOME/tmp_) bash -c 'ls' Parent pid 143110, child pid 143111 Child process initialized in 25.74 ms ls: cannot open directory '.': Permission denied Parent is shutting down, bye... ~~~~ What is the recommended way to jail application in a fake user's home to hide certain locations that application have no business accessing? firejail version 0.9.54 Thanks.

gitea-mirror commented 2026-05-05 08:05:59 -06:00

Author

Owner

Copy link

@smitsohu commented on GitHub (Sep 14, 2018):

Could you please re-run this command with --debug-whitelists?

<!-- gh-comment-id:421492337 --> @smitsohu commented on GitHub (Sep 14, 2018): Could you please re-run this command with `--debug-whitelists`?

gitea-mirror commented 2026-05-05 08:06:00 -06:00

Author

Owner

Copy link

@onlyjob commented on GitHub (Sep 15, 2018):

Thank you.

$ firejail --noprofile --debug-whitelists --whitelist=$(readlink -f $HOME/tmp_) bash -c 'ls'
Parent pid 123974, child pid 123975
Debug 424: new_name #/mnt/r/home/user/tmp_#, whitelist
real path /mnt/r/home/user/tmp_
Mounting tmpfs on /mnt directory
Whitelisting /mnt/r/home/user/tmp_
Child process initialized in 53.73 ms
ls: cannot open directory '.': Permission denied

Parent is shutting down, bye...

/home/user is a symlink: /home/user -> /mnt/r/home/user.

I think the Mounting tmpfs on /mnt directory in the output looks suspicious and possibly suggests a bug in the assumption that user's home is two levels deep from the root?

<!-- gh-comment-id:421549502 --> @onlyjob commented on GitHub (Sep 15, 2018): Thank you. ~~~~ $ firejail --noprofile --debug-whitelists --whitelist=$(readlink -f $HOME/tmp_) bash -c 'ls' Parent pid 123974, child pid 123975 Debug 424: new_name #/mnt/r/home/user/tmp_#, whitelist real path /mnt/r/home/user/tmp_ Mounting tmpfs on /mnt directory Whitelisting /mnt/r/home/user/tmp_ Child process initialized in 53.73 ms ls: cannot open directory '.': Permission denied Parent is shutting down, bye... ~~~~ `/home/user` is a symlink: `/home/user -> /mnt/r/home/user`. I think the `Mounting tmpfs on /mnt directory` in the output looks suspicious and possibly suggests a bug in the assumption that user's home is two levels deep from the root?

gitea-mirror commented 2026-05-05 08:06:00 -06:00

Author

Owner

Copy link

@smitsohu commented on GitHub (Sep 15, 2018):

Hmmm. I have trouble reproducing your issue. I created a new user, let's call him tester, a symbolic link /home/tester -> /mnt/bla/tester, and two files /mnt/bla/tester/abc and xyz. This is what I get:

tester@smitsohu:~$ firejail --noprofile --whitelist=$(readlink -f $HOME/abc) bash -c 'ls'
Parent pid 9015, child pid 9016
Child process initialized in 29.38 ms
abc

Parent is shutting down, bye...

Are you doing something special, maybe with FUSE?

<!-- gh-comment-id:421641175 --> @smitsohu commented on GitHub (Sep 15, 2018): Hmmm. I have trouble reproducing your issue. I created a new user, let's call him tester, a symbolic link /home/tester -> /mnt/bla/tester, and two files /mnt/bla/tester/abc and xyz. This is what I get: ``` tester@smitsohu:~$ firejail --noprofile --whitelist=$(readlink -f $HOME/abc) bash -c 'ls' Parent pid 9015, child pid 9016 Child process initialized in 29.38 ms abc Parent is shutting down, bye... ``` Are you doing something special, maybe with FUSE?

gitea-mirror commented 2026-05-05 08:06:01 -06:00

Author

Owner

Copy link

@onlyjob commented on GitHub (Sep 15, 2018):

But in my case tmp_ is a directory...
Yes, users' homes are on FUSE, /mnt/r is FUSE-mounted.

<!-- gh-comment-id:421651876 --> @onlyjob commented on GitHub (Sep 15, 2018): But in my case `tmp_` is a directory... Yes, users' homes are on FUSE, `/mnt/r` is FUSE-mounted.

gitea-mirror commented 2026-05-05 08:06:02 -06:00

Author

Owner

Copy link

@smitsohu commented on GitHub (Sep 16, 2018):

Probably this is caused by FUSE. The underlying reason is that when it comes to FUSE, even the powers of the root user are limited, and Firejail needs root for setting up the sandbox.

What you could try is mounting users' homes with allow_other or allow_root option, depending on who is doing the mount, root or regular user.

For comparing there are a number of similar issues, for instance #1560, but the behavior of whitelisting has changed slightly in the meantime, so you won't be able to reproduce all examples exactly.

<!-- gh-comment-id:421660788 --> @smitsohu commented on GitHub (Sep 16, 2018): Probably this is caused by FUSE. The underlying reason is that when it comes to FUSE, even the powers of the root user are limited, and Firejail needs root for setting up the sandbox. What you could try is mounting users' homes with `allow_other` or `allow_root` option, depending on who is doing the mount, root or regular user. For comparing there are a number of similar issues, for instance #1560, but the behavior of whitelisting has changed slightly in the meantime, so you won't be able to reproduce all examples exactly.

gitea-mirror commented 2026-05-05 08:06:03 -06:00

Author

Owner

Copy link

@onlyjob commented on GitHub (Sep 16, 2018):

I did not expect any problems with FUSE because it is mounted by root with user_allow_other. We have all users' homes on network share and mount point already have allow_other...

<!-- gh-comment-id:421667733 --> @onlyjob commented on GitHub (Sep 16, 2018): I did not expect any problems with FUSE because it is mounted by root with `user_allow_other`. We have all users' homes on network share and mount point already have `allow_other`...

gitea-mirror commented 2026-05-05 08:06:04 -06:00

Author

Owner

Copy link

@smitsohu commented on GitHub (Sep 16, 2018):

Ok, then it must be something else. Are you maybe employing NFS?

<!-- gh-comment-id:421817037 --> @smitsohu commented on GitHub (Sep 16, 2018): Ok, then it must be something else. Are you maybe employing NFS?

gitea-mirror commented 2026-05-05 08:06:05 -06:00

Author

Owner

Copy link

@onlyjob commented on GitHub (Sep 16, 2018):

If it were NFS I would probably had it mounted using kernel client rather than through FUSE... ;)

We are using LizardFS - distributed parallel file system. It have built-in data integrity, no single point of failure, good performance, etc.

<!-- gh-comment-id:421845789 --> @onlyjob commented on GitHub (Sep 16, 2018): If it were NFS I would probably had it mounted using kernel client rather than through FUSE... ;) We are using LizardFS - distributed parallel file system. It have built-in data integrity, no single point of failure, good performance, etc.

gitea-mirror commented 2026-05-05 08:06:05 -06:00

Author

Owner

Copy link

@smitsohu commented on GitHub (Sep 17, 2018):

I see. Maybe someone else with an idea?

<!-- gh-comment-id:421965508 --> @smitsohu commented on GitHub (Sep 17, 2018): I see. Maybe someone else with an idea?

gitea-mirror commented 2026-05-05 08:06:05 -06:00

Author

Owner

Copy link

@rusty-snake commented on GitHub (Jun 26, 2019):

@onlyjob does --private=~/tmp_ or --private-home=tmp_ work for you. Note: that they don't do exactly the same.

<!-- gh-comment-id:505774240 --> @rusty-snake commented on GitHub (Jun 26, 2019): @onlyjob does `--private=~/tmp_` or `--private-home=tmp_` work for you. Note: that they don't do exactly the same.

gitea-mirror commented 2026-05-05 08:06:06 -06:00

Author

Owner

Copy link

@rusty-snake commented on GitHub (Oct 13, 2019):

I'm closing here due to inactivity, please fell free to reopen if you still have this issue.

<!-- gh-comment-id:541427530 --> @rusty-snake commented on GitHub (Oct 13, 2019): I'm closing here due to inactivity, please fell free to reopen if you still have this issue.

gitea-mirror commented 2026-05-05 08:06:06 -06:00

Author

Owner

Copy link

@onlyjob commented on GitHub (Oct 13, 2019):

Sorry I could not get to this issue earlier. I have upgraded my system to Debian 10 "buster" and firejail version 0.9.58.2.

--private=~/tmp_ is not what I need;
--private-home=tmp_ appears to behave similar to --whitelist=~/tmp_ but warns: Error fcopy: size limit of 500MB reached.

The original problem with --whitelist=~/tmp_ is gone.
However with symlinked home directory firejail still does not work properly by default:

$ ls -l ~
/home/user -> /mnt/r/home/user

$ pwd
/home/user

$ firejail --whitelist=~/tmp_ bash
$ pwd
/mnt/r/home/user

Note how under Firejail current working directory changed to /mnt/r/home/user and ls still show all files in the home directory unless I cd ~ under firejail.

For me the correct invocation of firejail is

firejail --whitelist=~/tmp_ --whitelist=$(readlink -f ~)/tmp_  bash

to hide symlinked home so I recommend to have a special workaround for symlinked home directories by default.

P.S. I can not "reopen" the ticket. There is only "Comment" button...

<!-- gh-comment-id:541468417 --> @onlyjob commented on GitHub (Oct 13, 2019): Sorry I could not get to this issue earlier. I have upgraded my system to Debian 10 "buster" and `firejail version 0.9.58.2`. `--private=~/tmp_` is not what I need; `--private-home=tmp_` appears to behave similar to `--whitelist=~/tmp_` but warns: `Error fcopy: size limit of 500MB reached`. The original problem with `--whitelist=~/tmp_` is gone. However with symlinked home directory firejail still does not work properly by default: ~~~~ $ ls -l ~ /home/user -> /mnt/r/home/user $ pwd /home/user $ firejail --whitelist=~/tmp_ bash $ pwd /mnt/r/home/user ~~~~ Note how under Firejail current working directory changed to `/mnt/r/home/user` and `ls` still show all files in the home directory unless I `cd ~` under firejail. For me the correct invocation of firejail is firejail --whitelist=~/tmp_ --whitelist=$(readlink -f ~)/tmp_ bash to hide symlinked home so I recommend to have a special workaround for symlinked home directories by default. P.S. I can not "reopen" the ticket. There is only "Comment" button...

gitea-mirror commented 2026-05-05 08:06:07 -06:00

Author

Owner

Copy link

@smitsohu commented on GitHub (Oct 14, 2019):

Not sure what your current Firejail version is, but as an outlook, the treatment of home directories outside of /home has changed in current master....

There should be now full support for whitelisting and everything else, with all bells and whistles and no need for workarounds. However, there is still a problem if the user's entry in the system password database (/etc/passwd usually) does not contain the resolved path to the home directory, but a path with a symbolic link.

In this case all we can do currently (in master) is ask the user/administrator to update the password database and provide a fully resolved path there. Once this is done, there should be no outstanding issues (in master).

<!-- gh-comment-id:541858449 --> @smitsohu commented on GitHub (Oct 14, 2019): Not sure what your current Firejail version is, but as an outlook, the treatment of home directories outside of /home has changed in current master.... There should be now full support for whitelisting and everything else, with all bells and whistles and no need for workarounds. However, there is still a problem if the user's entry in the system password database (/etc/passwd usually) does not contain the resolved path to the home directory, but a path with a symbolic link. In this case all we can do currently (in master) is ask the user/administrator to update the password database and provide a fully resolved path there. Once this is done, there should be no outstanding issues (in master).

gitea-mirror commented 2026-05-05 08:06:07 -06:00

Author

Owner

Copy link

@smitsohu commented on GitHub (Oct 14, 2019):

--private-home=tmp_ appears to behave similar to --whitelist=~/tmp_ but warns: Error fcopy: size limit of 500MB reached.

In current master that limit is configurable in /etc/firejail/firejail.config

<!-- gh-comment-id:541866455 --> @smitsohu commented on GitHub (Oct 14, 2019): > --private-home=tmp_ appears to behave similar to --whitelist=~/tmp_ but warns: Error fcopy: size limit of 500MB reached. In current master that limit is configurable in /etc/firejail/firejail.config

gitea-mirror commented 2026-05-05 08:06:07 -06:00

Author

Owner

Copy link

@onlyjob commented on GitHub (Oct 15, 2019):

I think firejail should always normalise user's HOME path with readlink -f. In our case use of symlinks is intentional. Basically this issue could be considered a vulnerability as without special workaround it is trivial to bypass firejail isolation by merely a symlink.

I wonder is --bind mount should be detected also?

<!-- gh-comment-id:541987811 --> @onlyjob commented on GitHub (Oct 15, 2019): I think firejail should always normalise user's HOME path with `readlink -f`. In our case use of symlinks is intentional. Basically this issue could be considered a vulnerability as without special workaround it is trivial to bypass firejail isolation by merely a symlink. I wonder is `--bind` mount should be detected also?

gitea-mirror commented 2026-05-05 08:06:08 -06:00

Author

Owner

Copy link

@smitsohu commented on GitHub (Oct 15, 2019):

I think firejail should always normalise user's HOME path with readlink -f

Yeah, this was the original plan. But as user directories literally can be everywhere, there is the unlikely but not inconceivable case where a user is able to control the readlink return value (using a symbolic link to trick Firejail into thinking the user directory is somewhere else). Because of this, Firejail trusts only the raw string extracted from /etc/passwd, which is guaranteed to be under control of root.

In our case use of symlinks is intentional.

You can continue using them. But now that you mention it, I realize Firejail does not create a full representation of the file system inside the sandbox, in that a symbolic link in /home would be absent inside the sandbox. Maybe we should detect this situation.

I wonder is --bind mount should be detected also?

They tend to be less problematic from a privilege management perspective, as FUSE and friends guarantee to not increase DAC permissions, and they require CAP_SYS_ADMIN. So instead of using a symbolic link, you can always also bind-mount. Generally speaking, mounts are less problematic for Firejail than symbolic links.

<!-- gh-comment-id:542124764 --> @smitsohu commented on GitHub (Oct 15, 2019): > I think firejail should always normalise user's HOME path with readlink -f Yeah, this was the original plan. But as user directories literally can be everywhere, there is the unlikely but not inconceivable case where a user is able to control the readlink return value (using a symbolic link to trick Firejail into thinking the user directory is somewhere else). Because of this, Firejail trusts only the raw string extracted from /etc/passwd, which is guaranteed to be under control of root. > In our case use of symlinks is intentional. You can continue using them. But now that you mention it, I realize Firejail does not create a full representation of the file system inside the sandbox, in that a symbolic link in /home would be absent inside the sandbox. Maybe we should detect this situation. > I wonder is --bind mount should be detected also? They tend to be less problematic from a privilege management perspective, as FUSE and friends guarantee to not increase DAC permissions, and they require CAP_SYS_ADMIN. So instead of using a symbolic link, you can always also bind-mount. Generally speaking, mounts are less problematic for Firejail than symbolic links.

gitea-mirror referenced this issue 2026-05-05 10:11:09 -06:00

[PR #1432] [MERGED] Gwenview: drop kbuildsycoca5 from private-bin #3961

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

serialize_remounts_v2

landlock_v4

landlock

release-0.9.64

release-0.9.62

gitlab_ci

LTSbase

fred_ctests

docs

0.9.80

0.9.80-rc1

0.9.78

0.9.76

0.9.76-rc4

0.9.76-rc3

0.9.76-rc2

0.9.76-rc1

0.9.74

landlock-split

0.9.72

0.9.72rc1

0.9.70

0.9.68

0.9.68rc1

0.9.66

0.9.66rc1

0.9.64.4

0.9.64.2

0.9.64

0.9.64rc1

0.9.62.4

0.9.62.2

0.9.62

0.9.56.2-LTS

0.9.60

0.9.60-rc1

0.9.58.2

0.9.58

0.9.58-rc1

0.9.56-LTS-release

0.9.56-LTS

0.9.56

0.9.56-rc1

0.9.54

0.9.54-rc2

0.9.54-rc1

0.9.52

0.9.38.12

0.9.50

0.9.50-rc1

0.9.48

0.9.46

0.9.46-rc1

0.9.44.10

0.9.44.8

0.9.44.6

0.9.38.10

0.9.44.4

0.9.38.8

0.9.44.2

0.9.44

0.9.44-rc1

0.9.38.4

0.9.42

0.9.42-rc2

0.9.38.2

0.9.42-rc1

disable-globalcfg

0.9.40

0.9.40-rc1

0.9.38

0.9.38-rc1

0.9.36

0.9.36-rc1

0.9.34

0.9.34-rc1

0.9.32

0.9.32-rc1

0.9.30

0.9.30-rc1

Labels

Clear labels   

LTS merge

  

LTS merge

  

bug

  

bug

  

converted-to-discussion

  

doc-todo

  

documentation

  

duplicate

  

enhancement

  

file-transfer

  

firecfg

  

firejail-in-firejail

  

firetools

  

graphics

  

help wanted

  

information_old

  

installation

  

invalid

  

modif

  

moved

  

needinfo

  

networking

  

notabug

  

notourbug

  

old-version

  

overlayfs

  

packaging

  

profile-request

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

question_old

  

removal

  

runtime-permissions

  

sandbox-ipc

  

security

  

stale

  

wiki

  

wiki

  

wontfix

  

wordpress

  

workaround

No labels

LTS merge

LTS merge

bug

bug

converted-to-discussion

doc-todo

documentation

duplicate

enhancement

file-transfer

firecfg

firejail-in-firejail

firetools

graphics

help wanted

information_old

installation

invalid

modif

moved

needinfo

networking

notabug

notourbug

old-version

overlayfs

packaging

profile-request

pull-request

question

question_old

removal

runtime-permissions

sandbox-ipc

security

stale

wiki

wiki

wontfix

wordpress

workaround

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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

No description provided.