docs: clarify filesystem directives #5388
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Dieterbe
commented
Oct 1, 2022
glitsj16
reviewed
Oct 1, 2022
glitsj16
reviewed
Oct 1, 2022
glitsj16
reviewed
Oct 1, 2022
glitsj16
requested changes
Oct 1, 2022
rusty-snake
reviewed
Oct 1, 2022
|
all feedback addressed. PTAL |
|
anything else i can do? |
kmk3
changed the title
kmk3
added
the
documentation
|
We can bring this whenever you find the time to rebase. |
kmk3
requested changes
Jun 18, 2024
| @@ -269,9 +279,13 @@ blacklist-nolog /usr/bin/gcc* | |||
| .TP | |||
| \fBbind directory1,directory2 | |||
| Mount-bind directory1 on top of directory2. This option is only available when running as root. | |||
| Directories will retain the ownership and permissions of the original directory being mounted over (directory2). | |||
| After termination, modificationss affect the overlay directory (directory1). | |||
There was a problem hiding this comment.
Suggested change
| After termination, modificationss affect the overlay directory (directory1). | |
| After termination, modifications affect the overlay directory (directory1). |
Fix typo.
Comment on lines
+282
to
+283
| Directories will retain the ownership and permissions of the original directory being mounted over (directory2). | ||
| After termination, modificationss affect the overlay directory (directory1). |
There was a problem hiding this comment.
Shouldn't it be (directory1) in both cases?
Comment on lines
+287
to
+288
| Files will retain the ownership and permissions of the original file being mounted over (file2). | ||
| After termination, deletes do not persist but writes affect the overlayed file (file1). |
There was a problem hiding this comment.
Shouldn't it be (file1) in both cases?
kmk3
reviewed
Jun 18, 2024
Comment on lines
+257
to
267
| .br | ||
|
|
||
| .br | ||
| Blacklisted files are visible, but will get ownership set to root:root | ||
| (unless the noroot option is active, in which case it'll be nobody:nobody). | ||
| They get a size of 0 bytes, permissions 400, and reset timestamps and extended attributes. | ||
| I/O operations (including deletes) on them will fail. | ||
| .br | ||
| Blacklisted directories are visible, but get permissions 400, | ||
| ownership set to root:root and reset timestamps. I/O operations on them will fail. | ||
|
|
There was a problem hiding this comment.
Suggested change
| .br | |
| .br | |
| Blacklisted files are visible, but will get ownership set to root:root | |
| (unless the noroot option is active, in which case it'll be nobody:nobody). | |
| They get a size of 0 bytes, permissions 400, and reset timestamps and extended attributes. | |
| I/O operations (including deletes) on them will fail. | |
| .br | |
| Blacklisted directories are visible, but get permissions 400, | |
| ownership set to root:root and reset timestamps. I/O operations on them will fail. | |
| .PP | |
| When a path that does not exist is blacklisted, nothing is done. | |
| When a path that exists is blacklisted, an empty file or directory is | |
| bind-mounted on top of the original one inside of the sandbox. | |
| .PP | |
| The empty file and directory are located in the following paths: | |
| .PP | |
| /run/firejail/firejail.ro.file | |
| /run/firejail/firejail.ro.dir | |
| .PP | |
| They are created only once and are bind-mounted on top of all blacklisted | |
| files/directories in all sandboxes, so the timestamps of all blacklisted paths | |
| are identical. | |
| Both are owned by root:root (or nobody:nobody if the \fBnoroot\fR option is | |
| active). | |
| Their permissions are set to 400 and they likely have no extended attributes. | |
| Since the bind-mounted file is empty, blacklisted files appear to have a size | |
| of 0 bytes. | |
| Given their ownership and permissions, I/O operations (including deletion) on | |
| blacklisted paths will fail. |
Clarify and format.
Comment on lines
+451
to
+453
| Mount an empty tmpfs filesystem on top of directory. Changes do not persist after termination. | ||
| Directories outside user home or not owned by the user are not allowed. Sandboxes running as root are exempt from these restrictions. | ||
| This directive has no effect for files (they appear unmodified and changes persist after termination). |
There was a problem hiding this comment.
Suggested change
| Mount an empty tmpfs filesystem on top of directory. Changes do not persist after termination. | |
| Directories outside user home or not owned by the user are not allowed. Sandboxes running as root are exempt from these restrictions. | |
| This directive has no effect for files (they appear unmodified and changes persist after termination). | |
| Mount an empty tmpfs filesystem on top of directory. | |
| Changes do not persist after termination. | |
| Directories outside of the user home or not owned by the user are not allowed. | |
| Sandboxes running as root are exempt from these restrictions. | |
| This directive has no effect for files (they appear unmodified and changes | |
| persist after termination). |
Format.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
i've been doing a bunch of experimenting in an attempt to clarify the specifics of what happens to files and directories in light of the various filesystem directives.
i have some simple shell scripts that test all the different scenarios with different profiles. If desired, I can share those too. (they're quite basic)
The only thing I'm not sure of is whether i/o operations might start working on blacklisted files/dirs when they are executed as root. I presume no, but I don't have time now to conduct such as experiment to make sure.