github-starred/firejail

Fork 0

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

[GH-ISSUE #3133] Dealing with symlinked ~/.cache #1968

New issue

Closed

opened 2026-05-05 08:37:48 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

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

Owner

Originally created by @haarp on GitHub (Jan 8, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3133

Greetings!

Currently experimenting with Firejail and liking it so far. :)

One problem I'm facing is the fact that I have ~/.cache symlinked to /tmp/cache-$USER. /tmp resides on tmpfs and the symlink target is mkdir'ed on login with perms 700.

Now firejail seems to set everything with perms 700 to be owned by nobody:nobody, making it impossible to access ~/.cache from within a sandbox.

Things I've tried so far:

private-cache: Would be the best solution, but fails with Warning: /home/haarp/.cache is a symbolic link, tmpfs not mounted. Is there no way to make tmpfs work on top of a symlink?
private-tmp: Could work, but I would have to mkdir /tmp/cache-$USER from within each sandbox before the actual app runs. This complicates things as I can't just run firejail foo anymore.
noblacklist /tmp/cache-$USER: Doesn't seem to have an effect of making it accessible.

Now I'm stumped. Any further ideas? I would like to avoid having to remove or replace the ~/.cache symlink.

Thanks!

Originally created by @haarp on GitHub (Jan 8, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3133 Greetings! Currently experimenting with Firejail and liking it so far. :) One problem I'm facing is the fact that I have `~/.cache` symlinked to `/tmp/cache-$USER`. `/tmp` resides on tmpfs and the symlink target is mkdir'ed on login with perms `700`. Now firejail seems to set everything with perms `700` to be owned by `nobody:nobody`, making it impossible to access `~/.cache` from within a sandbox. Things I've tried so far: - `private-cache`: Would be the best solution, but fails with `Warning: /home/haarp/.cache is a symbolic link, tmpfs not mounted`. Is there no way to make tmpfs work on top of a symlink? - `private-tmp`: Could work, but I would have to mkdir `/tmp/cache-$USER` from within each sandbox before the actual app runs. This complicates things as I can't just run `firejail foo` anymore. - `noblacklist /tmp/cache-$USER`: Doesn't seem to have an effect of making it accessible. Now I'm stumped. Any further ideas? I would like to avoid having to remove or replace the `~/.cache` symlink. Thanks!

gitea-mirror closed this issue

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

gitea-mirror commented

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

Author

Owner

@haarp commented on GitHub (Jan 8, 2020):

Ok, I figured it out the final point. There is no automatic blacklisting. I had ~/.nv symlinked to ~/.cache. ~/.nv is blacklisted by default in disable-programs.inc. It appears blacklisting traverses the entire symlink chain and actually blacklists the final target.

If noblacklist is to succeed, it needs to be applied to the path which triggered the blacklist in the first place. In this case, noblacklist ${HOME}/.nv.

Maybe the manpage should be updated with this information? I'm probably not the only one who was struggling to figure this out :) Cheers!

(I still would like to know if there's a way to mount tmpfs over symlinks tho)

@haarp commented on GitHub (Jan 8, 2020): Ok, I figured it out the final point. There is no automatic blacklisting. I had `~/.nv` symlinked to `~/.cache`. `~/.nv` is blacklisted by default in `disable-programs.inc`. It appears blacklisting traverses the entire symlink chain and actually blacklists the final target. If noblacklist is to succeed, it needs to be applied to the path which triggered the blacklist in the first place. In this case, `noblacklist ${HOME}/.nv`. Maybe the manpage should be updated with this information? I'm probably not the only one who was struggling to figure this out :) Cheers! (I still would like to know if there's a way to mount tmpfs over symlinks tho)

gitea-mirror commented

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

Author

Owner

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

Now firejail seems to set everything with perms 700 to be owned by nobody:nobody, making it impossible to access ~/.cache from within a sandbox.

Not sure I understand that part, could you provide a command? Does your user own that directory?

@smitsohu commented on GitHub (Jan 15, 2020): > Now firejail seems to set everything with perms 700 to be owned by nobody:nobody, making it impossible to access ~/.cache from within a sandbox. Not sure I understand that part, could you provide a command? Does your user own that directory?

gitea-mirror commented

2026-05-05 08:37:52 -06:00

Author

Owner

@haarp commented on GitHub (Jan 15, 2020):

Not sure I understand that part, could you provide a command? Does your user own that directory?

I was wrong about that, please see my second comment.

@haarp commented on GitHub (Jan 15, 2020): > Not sure I understand that part, could you provide a command? Does your user own that directory? I was wrong about that, please see my second comment.

gitea-mirror commented

2026-05-05 08:37:53 -06:00

Author

Owner

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

Then, am I right in assuming that it works just fine if there is 1) no private-tmp, 2) no whitelisting in user home and if 3) noblacklist ${HOME}/.nv is added to a file /etc/firejail/disable-programs.local?

For issues associated with whitelisting in user home there is a simple solution: Just create a file /etc/firejail/whitelist-common.local and put whitelist ${HOME}/.cache inside; this way the link is always replicated inside the sandbox.

Regarding private-tmp your only option currently is to modify the stock profiles: Create files with the same name and a .local ending and put the new directive inside, either mkdir /tmp/cache-$USER or whitelist /tmp/cache-$USER.
The former basically is the same as private-cache, whereas in the latter case all reads and writes leave the sandbox and go to the shared cache directory.

I still would like to know if there's a way to mount tmpfs over symlinks tho

Currently not, because of security considerations.

@smitsohu commented on GitHub (Jan 15, 2020): Then, am I right in assuming that it works just fine if there is 1) no `private-tmp`, 2) no whitelisting in user home and if 3) `noblacklist ${HOME}/.nv` is added to a file /etc/firejail/disable-programs.**local**? For issues associated with whitelisting in user home there is a simple solution: Just create a file /etc/firejail/whitelist-common.local and put `whitelist ${HOME}/.cache` inside; this way the link is always replicated inside the sandbox. Regarding `private-tmp` your only option currently is to modify the stock profiles: Create files with the same name and a .local ending and put the new directive inside, either `mkdir /tmp/cache-$USER` or `whitelist /tmp/cache-$USER`. The former basically is the same as `private-cache`, whereas in the latter case all reads and writes leave the sandbox and go to the shared cache directory. > I still would like to know if there's a way to mount tmpfs over symlinks tho Currently not, because of security considerations.

gitea-mirror commented

2026-05-05 08:37:53 -06:00

Author

Owner

@haarp commented on GitHub (Jan 17, 2020):

Then, am I right in assuming that it works just fine if there is 1) no private-tmp, 2) no whitelisting in user home and if 3) noblacklist ${HOME}/.nv is added to a file /etc/firejail/disable-programs.local?

Correct!

and put whitelist ${HOME}/.cache inside; this way the link is always replicated inside the sandbox.

But whitelisting .cache will hide (almost) the entire home directory instead. That's a fairly impactful side-effect.

and put the new directive inside, either mkdir /tmp/cache-$USER

Oh wow. I just realized that mkdir is an actual directive. Turns out there's more than just the firejail manpage. This'll come in handy, thanks!

In conclusion, here are the possible ways of dealing with this problem:

get rid of the ~/.nv symlink
use noblacklist, but it has to be used on the path that triggered the blacklist in the first place (~/.nv), not its symlink target (~/.cache), or its target (/tmp/cache-$user). This behavior should be documented IMO.
use private-tmp together with mkdir /tmp/cache-$user

Cheers!

@haarp commented on GitHub (Jan 17, 2020): > Then, am I right in assuming that it works just fine if there is 1) no private-tmp, 2) no whitelisting in user home and if 3) noblacklist ${HOME}/.nv is added to a file /etc/firejail/disable-programs.local? Correct! > and put whitelist ${HOME}/.cache inside; this way the link is always replicated inside the sandbox. But whitelisting .cache will hide (almost) the entire home directory instead. That's a fairly impactful side-effect. > and put the new directive inside, either mkdir /tmp/cache-$USER Oh wow. I just realized that `mkdir` is an actual directive. Turns out there's more than just the `firejail` manpage. This'll come in handy, thanks! In conclusion, here are the possible ways of dealing with this problem: - get rid of the `~/.nv` symlink - use `noblacklist`, but it has to be used on the path that triggered the blacklist in the first place (`~/.nv`), not its symlink target (`~/.cache`), or its target (`/tmp/cache-$user`). This behavior should be documented IMO. - use `private-tmp` together with `mkdir /tmp/cache-$user` Cheers!

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

No description provided.

Rows
Columns