mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #1115] better self-explaining options (than --private) #763
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#763
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 @testbird on GitHub (Feb 26, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1115
firejail could make the meaning of its options much more clearer by providing a more self-explaining alternative. (e.g. the meaning of the --private options seems not very clear to me all the time.)
What would you think about a scheme along these lines:
--private could have more clearly named alternatives like this:
--persistent-home=/home/$USER (the default, make permanent changes to the settings)
--discardable-home=/home/$USER (starting with some existing settings)
--discardable-home (defaults to =$HOME)
--discardable-home=/home/$USER --home-whitelist=.directory,file,etc, (adding restrictions)
--discardable-home=empty (the legacy --private, resulting in starting with the programs default settings)
NB: Currently there seems to be an inconsistency:
--private provides a discardable version of an empty home, but
--private=own_subdir uses ~/own_subdir as persistent storage.
@netblue30 commented on GitHub (Feb 28, 2017):
You are right, it is not consistent in this moment. It just evolved this way over time, and is kind of difficult to change it now. I'll look into it.
@testbird commented on GitHub (Feb 28, 2017):
Ah, well, understandable! Good to know you keep the wording in mind.
Once it has matured you may add the new options as mutually exclusive to the old ones, and then use the new ones in explanations.
@netblue30 commented on GitHub (Mar 3, 2017):
Absolutely, it will go through a major cleanup before 1.0 release.