You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During review of #5706 and #5707 some skepticism was voiced against tying a non-obvious link between profiles. It's not the first time we see a profile being implemented correctly yet in a way that limits user-choice. In these two particular cases new profiles are directly tied to mpv, although any media-player with streaming capabilities could be used. Admittedly I myself was originally in favor of asking the OP to consider refactoring their newly suggested profiles as mpv redirects. Sleeping on it completely changed my views. Whenever it is perfectly possible to loosely couple profiles, we should do so.
Whether such a design approach implies slightly more complex include logic and/or more work shouldn't become obstacles to at least try to develop profiles and code with user-choice baked in from the outset. The below examples refer to #5707, but IMO also apply to other work.
$ cat /etc/firejail/ani-cli.profile
# Firejail profile for ani-cli
# Description: Shell script to watch Anime from the terminal
# This file is overwritten after every install/update
quiet
# Persistent local customizations
include ani-cli.local
# Persistent global definitions
include globals.local
noblacklist ${HOME}/.cache/ani-cli
noblacklist ${HOME}/.local/state/ani-cli
# Allow /bin/sh (blacklisted by disable-shell.inc)
include allow-bin-sh.inc
# Allow lua (blacklisted by disable-interpreters.inc)
include allow-lua.inc
# Allow python (blacklisted by disable-interpreters.inc)
include allow-python2.inc
include allow-python3.inc
blacklist /usr/libexec
include disable-common.inc
include disable-devel.inc
include disable-exec.inc
include disable-interpreters.inc
include disable-proc.inc
include disable-programs.inc
include disable-shell.inc
include disable-xdg.inc
mkdir ${HOME}/.cache/ani-cli
mkdir ${HOME}/.local/state/ani-cli
whitelist ${DOWNLOADS}
whitelist ${HOME}/.cache/ani-cli
whitelist ${HOME}/.local/state/ani-cli
whitelist /usr/share/lua
whitelist /usr/share/lua*
whitelist /usr/share/vulkan
include whitelist-common.inc
include whitelist-media-players-common.inc
include whitelist-run-common.inc
include whitelist-runuser-common.inc
include whitelist-usr-share-common.inc
include whitelist-var-common.inc
apparmor
caps.drop all
netfilter
nodvd
nogroups
noinput
nonewprivs
noprinters
noroot
notv
nou2f
protocol unix,inet,inet6,netlink
seccomp
seccomp.block-secondary
tracelog
disable-mnt
private-bin ani-cli,cat,cp,curl,cut,env,ffmpeg,fzf,grep,head,lua*,mkdir,mv,nl,python*,sed,sh,sort,tput,tr,uname,wc
#private-cache
private-dev
private-etc alsa,alternatives,asound.conf,ca-certificates,crypto-policies,fonts,host.conf,hostname,hosts,ld.so.cache,ld.so.conf,ld.so.conf.d,ld.so.preload,locale,locale.alias,locale.conf,localtime,machine-id,mime.types,mpv,nsswitch.conf,pango,pki,protocols,pulse,resolv.conf,rpc,services,ssl,X11,xdg
private-tmp
dbus-user none
dbus-system none
read-only ${HOME}
read-write ${HOME}/.cache/ani-cli
read-write ${HOME}/.local/state/ani-cli
restrict-namespaces
Here's the newly introduced whitelist-media-players-common.inc file that loosely-couples ani-cli to (most if not all) existing firejailed media players:
I've opted to keep these remarks out of pending reviews of #5706 and #5707. Those will get merged in one form or another and can always be approached again later. The main focus here is to collect thoughts/ideas on whether such a loose-coupling with user-choice in mind is actually a direction to consider for the Firejail project as a whole.
Another obvious example would be supporting more than just Firefox in web browser related work. IMO we're getting pretty close to achieving this. Work done on #5364, #5566, #5582 and related issues could really benefit users. We 'd 'just' need to take care of the profiles side and ensure the crux of these tools - the UNIX domain socket - is accessible in the relevant files.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
During review of #5706 and #5707 some skepticism was voiced against tying a non-obvious link between profiles. It's not the first time we see a profile being implemented correctly yet in a way that limits user-choice. In these two particular cases new profiles are directly tied to mpv, although any media-player with streaming capabilities could be used. Admittedly I myself was originally in favor of asking the OP to consider refactoring their newly suggested profiles as mpv redirects. Sleeping on it completely changed my views.
Whenever it is perfectly possible to loosely couple profiles, we should do so.
Whether such a design approach implies slightly more complex include logic and/or more work shouldn't become obstacles to at least try to develop profiles and code with user-choice baked in from the outset. The below examples refer to #5707, but IMO also apply to other work.
$ cat /etc/firejail/ani-cli.profile
Here's the newly introduced
whitelist-media-players-common.inc
file thatloosely-couples
ani-cli to (most if not all) existing firejailed media players:$ cat /etc/firejail/whitelist-media-players-common.inc
I've opted to keep these remarks out of pending reviews of #5706 and #5707. Those will get merged in one form or another and can always be approached again later. The main focus here is to collect thoughts/ideas on whether such a
loose-coupling with user-choice in mind
is actually a direction to consider for the Firejail project as a whole.Another obvious example would be supporting more than just Firefox in web browser related work. IMO we're getting pretty close to achieving this. Work done on #5364, #5566, #5582 and related issues could really benefit users. We 'd 'just' need to take care of the profiles side and ensure the crux of these tools - the UNIX domain socket - is accessible in the relevant files.
For reference, this relates to:
Beta Was this translation helpful? Give feedback.
All reactions