mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3041] Document the algorithm used to determine firejail behavior for virtual paths #1907
Labels
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
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1907
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @KOLANICH on GitHub (Nov 13, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3041
Currrently there are multiple options:
blacklist,noblacklist,whitelist,read-only,read-write,private*, etc.But it is completely unclear how firejail uses them.
We need a high-level description of the algo. Let we have for each virtual path that can be interacted from the sandbox the following attrs, describing firejail behavior for that path:
visible- If it is 1, an app in sandbox sees the path in directory listing, if it is present in fs outside of sandbox. If it is 0, the app doesn't see the file.read-allowed- the app can read the virtual file having this virtual path. It means there is no permission error and virtual fs attrs look as needed. Semantics is defined by other attrs.write-allowed- the app can write the virtual file having this virtual path. It means there is no permission error and virtual fs attrs look as needed. Semantics is defined by other attrs.execute-allowed- the app can execute the virtual file having this virtual path. It means there is no permission error and virtual fs attrs look as needed.write-passthrough- the path of the file in the real fs. When a virtual file is written with some content, this file in real fs is written. Can benull, this means that the real file is not written, but an ephemerial one is created.read-passthrough- the path of the file in the real fs. When a virtual file is read, this file in real fs is read and its content is returned. For non-existent or non-visiblepaths assummed to be equal to theirwrite-passthrough.So in this model we should define:
1 the function generating default attrs of each virtual path
2 how each config param affects virtual path attrs