Closed glitsj16 closed 4 months ago
Shell redirection is a feature of your shell. i.e. the process that writes to ~/.bashrc
in the following process tree is the bash process that wraps/starts firejail.
-bash
|-firejail --private
|-cat
@rusty-snake on Jul 6:
Shell redirection is a feature of your shell. i.e. the process that writes to
~/.bashrc
in the following process tree is the bash process that wraps/starts firejail.
The shell indeed opens the file and sets up the redirection before firejail starts, though I think that technically the child process is still the one that writes to the stream.
@glitsj16
Can you reproduce this without shell redirects?
Well, technically your right. Though it only helps if you understand the difference between open and read/write.
Can you reproduce this without shell redirects?
All good without shell redirection:
$ firejail --quiet --private -- sh -c 'echo "#test" >> "${HOME}/.bashrc"'
sh: line 1: /home/glitsj16/.bashrc: Read-only file system
firejail --quiet --private --blacklist="${HOME}/.bashrc" -- sh -c 'echo "#test" >> "${HOME}/.bashrc"'
sh: line 1: /home/glitsj16/.bashrc: Permission denied
Sorry for the noise.
Yesterday on IRC something odd came up regarding the
private
option. Expecting this option to create a sandbox in which all modifications getdiscarded
at shutdown, it turns out this isn't respected.The following command variations all allow editing ${HOME}/.bashrc:
So, to summarize:
read-only
viadisable-common.inc
(included fromdefault.profile
) is not being enforced;private
shouldn't allow this;blacklisting
${HOME}/.bashrc is not preventing this from happening.This easy and unexpected circumvention of the above restrictions make me wonder what is actually causing this (besides apparent shell redirection). I could use a sanity check here :)
Note: I'm seeing this on my
firejail-git
, but a user confirmed this also happens on0.9.72
.