github-starred/firejail

Fork 0

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

[GH-ISSUE #3201] How to make applications have access to a virtual filepath (like flatpak does) #2004

New issue

Closed

opened 2026-05-05 08:40:26 -06:00 by gitea-mirror · 8 comments

gitea-mirror commented

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

Owner

Originally created by @Joe23232 on GitHub (Feb 5, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3201

So with flatpak if you download something like Steam, Steam has access to and virtual file paths, therefore games get installed in the virtual filepath, but with the download directory, it has access to the real download directory.

How would I do this with firejail?

Originally created by @Joe23232 on GitHub (Feb 5, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3201 So with flatpak if you download something like Steam, Steam has access to and virtual file paths, therefore games get installed in the virtual filepath, but with the download directory, it has access to the real download directory. How would I do this with firejail?

gitea-mirror

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

closed this issue
added the
information_old
label

gitea-mirror commented

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

Author

Owner

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

I'm not really familiar with Steam, but you might want to take a look at the --private= option.

In a profile it could look like

mkdir ${HOME}/fakehome
private ${HOME}/fakehome

In this case the app would always see ~/fakehome instead of the real home directory.

@smitsohu commented on GitHub (Feb 5, 2020): I'm not really familiar with Steam, but you might want to take a look at the `--private=` option. In a profile it could look like ``` mkdir ${HOME}/fakehome private ${HOME}/fakehome ``` In this case the app would always see ~/fakehome instead of the real home directory.

gitea-mirror commented

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

Author

Owner

@Joe23232 commented on GitHub (Feb 5, 2020):

@smitsohu So this creates a fakehome directory and what does private ${HOME}/fakehome this do exactly?

Can the application still see the root directory and external drives's contents that are connected to my PC?

@Joe23232 commented on GitHub (Feb 5, 2020): @smitsohu So this creates a `fakehome` directory and what does `private ${HOME}/fakehome` this do exactly? Can the application still see the root directory and external drives's contents that are connected to my PC?

gitea-mirror commented

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

Author

Owner

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

So this creates a fakehome directory and what does private ${HOME}/fakehome this do exactly?

It makes the app see ~/fakehome instead of the real home directory.
Just try it out :)

Can the application still see the root directory and external drives's contents that are connected to my PC?

The --private= option is not sufficient to create a complete sandbox, obviously.

But it is my superficial understanding that all games and settings are stored in the user home directory. For everything else there are other precautions and other options (default read-only filesystem, blacklisting, disable-mnt, ...), and you can also use more of the private options (private-bin, private-etc, ...) to "virtualize" other parts of the file system.

@smitsohu commented on GitHub (Feb 5, 2020): > So this creates a fakehome directory and what does private ${HOME}/fakehome this do exactly? It makes the app see ~/fakehome instead of the real home directory. Just try it out :) > Can the application still see the root directory and external drives's contents that are connected to my PC? The `--private=` option is not sufficient to create a complete sandbox, obviously. But it is my superficial understanding that all games and settings are stored in the user home directory. For everything else there are other precautions and other options (default read-only filesystem, blacklisting, `disable-mnt`, ...), and you can also use more of the private options (`private-bin`, `private-etc`, ...) to "virtualize" other parts of the file system.

gitea-mirror commented

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

Author

Owner

@Joe23232 commented on GitHub (Feb 5, 2020):

Probably I want to virtualise everything but the downloads directory. So if the home directory is virtualised, is it possible to still allow the application to ONLY have access to the real Downloads' directory?

@Joe23232 commented on GitHub (Feb 5, 2020): Probably I want to virtualise everything but the downloads directory. So if the home directory is virtualised, is it possible to still allow the application to ONLY have access to the real Downloads' directory?

gitea-mirror commented

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

Author

Owner

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

You will need to make some kind of compromise. The alternative to the private options is whitelist. There, a top level directory is "virtualized", so to say, but holes are punched in this virtualization for user defined files and directories. In a profile that translates to simply

whitelist ${DOWNLOADS}

If Flatpak does a combination of those two things, this is something that users currently cannot do in Firejail.

Btw, only in case I was unclear, all modifications in ~/fakehome (the --private= option suggested above) are persistent. So the sandbox just has its own Downloads directory.

@smitsohu commented on GitHub (Feb 6, 2020): You will need to make some kind of compromise. The alternative to the `private` options is `whitelist`. There, a top level directory is "virtualized", so to say, but holes are punched in this virtualization for user defined files and directories. In a profile that translates to simply ``` whitelist ${DOWNLOADS} ``` If Flatpak does a combination of those two things, this is something that users currently cannot do in Firejail. Btw, only in case I was unclear, all modifications in ~/fakehome (the `--private=` option suggested above) are persistent. So the sandbox just has its own Downloads directory.

gitea-mirror commented

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

Author

Owner

@Joe23232 commented on GitHub (Feb 6, 2020):

Is there a command which virtualises everything all in one go?

@Joe23232 commented on GitHub (Feb 6, 2020): Is there a command which virtualises everything all in one go?

gitea-mirror commented

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

Author

Owner

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

Ok, it is possible to get rather close to that end with the --overlay and --chroot options. For example, it could look like:

firejail --private-tmp --private-dev --overlay-named=somename

Unfortunately there is currently a bug in the overlay implementation (kernels > 4.19). So if a complete chroot is in scope, the answer is probably yes. Otherwise the answer is probably no (edit: until the issue with overlay is resolved).

@smitsohu commented on GitHub (Feb 6, 2020): Ok, it is possible to get rather close to that end with the `--overlay` and `--chroot` options. For example, it could look like: `firejail --private-tmp --private-dev --overlay-named=somename` Unfortunately there is currently a bug in the overlay implementation (kernels > 4.19). So if a complete chroot is in scope, the answer is probably yes. Otherwise the answer is probably no (edit: until the issue with overlay is resolved).

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Mar 14, 2020):

I'm closing here due to inactivity, please fell free to reopen if you have more questions.

@rusty-snake commented on GitHub (Mar 14, 2020): I'm closing here due to inactivity, please fell free to reopen if you have more questions.

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

No description provided.

Rows
Columns