Open oliversturm opened 3 years ago
I cannot reproduce this with firejail from master and gocryptfs 1.8.0 on Fedora 33.
Can you trying using plain bash (if you aren't)?
I was using zsh, but I just tried the same thing in bash and the behavior remains the same.
So... it looks to me as if firejail is doing something that uses the current working directory, while it attempts to load qpdfview.local
via the include
instruction. And whatever that is, it fails when CWD is on a gocryptfs mount. I was almost expecting that somebody with good knowledge of the code would have an idea quickly - but apparently no such luck :)
firejail will fail on fuse mounts w/o allow_root
or allow_other
. Does it work with one of them?
Hm... haven't tested this yet. I saw something about this previously, but I obviously assumed that it would apply only if any of the data relevant to firejail was actually stored on that mount. In my case, it's only the current working directory that is on the mount, but there is no reason for firejail to look at this working directory. And in fact it all works fine - if I use --noprofile
or comment the include
line in the profile. So are you sure there is a reason here that the mount parameters should be at fault?
For instance, this works perfectly fine for me. I'm accessing a file that is on the mount, but the current working directory is not on the mount.
➜ pwd
/home/sturm
➜ firejail /usr/bin/qpdfview /home/sturm/cryptmount/test.pdf
Somehow read the mount
output above like $HOME was the mount. Anyway, the relevant is
The issues seems to be that include foobar
first tries ~/.config/firejail and /etc/firejail. If foobar is not found there, it is looked up in CWD. But the call to access
returns EPERM (or something else but not EACCES).
EDIT: Reason for failing on EPERM: https://github.com/netblue30/firejail/issues/3478#issuecomment-650584693 and all following.
To confirm, when I mount gocryptfs with allow_other
, the problem goes away. And... here's your code snippet. Yeah, that explains it.
I don't entirely agree with this comment:
I think if a .local file exists but has wrong permissions, we should also exit, so the user can fix it.
I think it would be better if we don't exit if a .local
file is found (or not) with inaccessible permissions. As this issue illustrates, there could be more than one reason for this, including the case where the current working directory can't even be accessed at all.
I want to keep failing on EPERM, since it indicates invalid/wrong configurations. However, include
does not need to lookup in cwd IMHO. I mean as long as /etc/firejail and ~/.config/firejail has a higher order, there is no good reason to look in cwd for a include
d profile (--profile and --include should look in cwd).
include
does not need to lookup in cwd
I agree with that - I thought this behavior was "on purpose". I think it could be potentially dangerous to check cwd for an include
instruction found in the main profile, because I may not realize that the cwd contains a .local
override file and I'm executing a command with a "special" configuration.
potentially dangerous
A program in a blacklisting sandbox could create it's own .local in cwd (usually ~) and add read-write ${HOME}/.bashrc
. After the next start, it can write to ~/.bashrc. However this does not work for whitelisting profiles, and blacklisting profiles can be escapes by just creating .config/{systemd,environmentd} for example. Those dirs are read on the most systemd and don't exists on the most systems.
All agreed. I wasn't thinking in such detail - just that I could be enticed somehow to download a file called tar.local
, and when I next use the tar
command while in ~/Downloads
, it would run with whatever profile modifications tar.local
applies - without me noticing.
FWIW / for search engines' benefit, the same problem occurs running firejail while sitting in an encfs filesystem, probably the same reason (pwd is a fuse filesystem not mounted with allow_*, etc.).
Also for completion and for the next one having the same problem and searching for it immediately being suggested this issue ticket:
When an SMB share is being mounted via gnome/nautilus/gvfs - path being e.g. /run/user/1000/gvfs/smb-share:server=nas.local,share=data/
- the same issue occurs.
Also for completion and for the next one having the same problem and searching for it immediately being suggested this issue ticket: When an SMB share is being mounted via gnome/nautilus/gvfs - path being e.g.
/run/user/1000/gvfs/smb-share:server=nas.local,share=data/
- the same issue occurs.
Yes, this is my issue with opening files from Thunar - I can drag and drop them to open in VLC or an editor, however I can't whitelist the gvfs mount location because it is no longer in my home directory.
My only workaround so far has been to symlink directly in /usr/local/bin eog, vlc, geany, and others so I don't run into this.
Also for completion and for the next one having the same problem and searching for it immediately being suggested this issue ticket: When an SMB share is being mounted via gnome/nautilus/gvfs - path being e.g.
/run/user/1000/gvfs/smb-share:server=nas.local,share=data/
- the same issue occurs.
This is super annoying. My NAS is pretty much unusable with a default firejail installation. I thought I could work around this by removing include evince.local
from the profile but then it goes on: cannot acces globals.local
, cannot access disable-common.local
, ... and many more to come.
Does anyone have a suggestion how to efficiently make this work?
AFAIK you can
touch
all the .local files in a location with a higher priority (e.g. /etc/firejail
)allow_root
/allow_other
to workaround.
AFAIK you can\n\ntouch all the .local files in a location with a higher priority (e.g. /etc/firejail)
That was a nice idea.
I created them by issuing for file in $(ls /etc/firejail); do touch /etc/firejail/$(echo $file | cut -d"." -f1).local; done
(might not be the cleanest option, but it worked).
However, evince still fails to open the file. When opening a PDF using the GUI, evince shows the correct file path (/run/user/1000/gvfs/long/path/to/SMB/folder/filename.pdf
), when opening a terminal in the same location, it shows /home/username/filename.pdf
as the filename.
In both cases the file open fails with "file or directory not found". I suppose this is a privilege issue, too?
Running from another cwd as in "start evince in another directory than open the file which is still located on the share" fails with the same error message. Copying the file to another directory would of course work, but is not very efficient. The same goes for "mount with options". Afaik, gvfs-mount does not really support the permanent configuration of custom mount options. So I would have to mount the SMB shares without gvfs, which would require a lot of re-configuration. I have set up multiple shares and am used to navigate them using gvfs.
Ultimately, I think that firejail should support gvfs shares out of the box if technically possible. This leaves "fix firejail" as only viable option, which I am unfortunately unable to do. However, I hope that my analysis can at least help others with the same issue.
First you need to distinct different issues here:
access
fails with something else than EACCES
. (fixable). This is why "running from a different cwd..."whitelist ${RUNUSER}/gvfs
it is better to discuss it in a new discussion.allow_root
/allow_other
where root (firejail) lacks permission to mount/access/... (not fixable at firejail's side).I understood this issue to be more about the allow_root/allow_other
mount option of fuse file systems, which is why I kept posting here.
To sum it up, I tried adding whitelist ${RUNUSER}/gvfs
and it still doesn't work, but the error message changed. Now firejail prints something like "whitelist_file: Permission denied".
I don't understand how my situation differs from the apparently working example described in https://github.com/netblue30/firejail/issues/3798#issuecomment-740765282, which is why I thought that there must be some other problem. It seems however that it ultimately all comes down to allow_root/allow_other
.
Thanks for your help anyway, I will try to evaluate some alternatives. I still consider mounting SMB shares via gvfs something that many Linux users might do, so it would be great to come up with a way to make this work with firejail.
Edit: If anyone else is facing the same problem, a possible workaround is described in https://askubuntu.com/questions/401454. I adapted it a bit to make it work on my system. In essence:
/etc/fuse.conf
so that it contains the line user_allow_other
[Desktop Entry]
Version=1.0
Type=Application
Name=Fuse Remount
Terminal=false
Exec=sh -c "fusermount -zu /run/user/<userid>/gvfs && /usr/libexec/gvfsd-fuse -o allow_root /run/user/<userid>/gvfs"
/etc/firejail/whitelist-runuser-common.local
and putting the line whitelist ${RUNUSER}/gvfs
in it.The next time you login, the autostart script should fire and remount the gvfs fuse file system with the crucial allow_root
option. Note that on my Fedora system, the path for gvfsd-fuse
differed from the one mentioned in the askubuntu post. This might be distribution specific.
I want to keep failing on EPERM, since it indicates invalid/wrong configurations. However,
include
does not need to lookup in cwd IMHO. I mean as long as /etc/firejail and ~/.config/firejail has a higher order, there is no good reason to look in cwd for ainclude
d profile (--profile and --include should look in cwd).
I would agree with not searching cwd (creates concerns similar to having .
in PATH
). I've also encountered something related: if I have a fuse filesystem mounted without user_allow_other
anywhere under my homedir, then firejail for various commands fails with the cannot access profile file: globals.local
error or similar regardless of my cwd. I did not dig in deeply at the time - just umounted/remounted those fuse filesystems and moved on.
If firejail only looked in /etc/firejail/
and ~/.config/firejail/
, seems there would be fewer surprises.
@hlein commented on Jan 9:
I want to keep failing on EPERM, since it indicates invalid/wrong configurations. However,
include
does not need to lookup in cwd IMHO. I mean as long as /etc/firejail and ~/.config/firejail has a higher order, there is no good reason to look in cwd for ainclude
d profile (--profile and --include should look in cwd).I would agree with not searching cwd (creates concerns similar to having
.
inPATH
). I've also encountered something related: if I have a fuse filesystem mounted withoutuser_allow_other
anywhere under my homedir, then firejail for various commands fails with thecannot access profile file: globals.local
error or similar regardless of my cwd. I did not dig in deeply at the time - just umounted/remounted those fuse filesystems and moved on.If firejail only looked in
/etc/firejail/
and~/.config/firejail/
, seems there would be fewer surprises.
I agree with not searching .
by default. If the use case is testing many
profile files on an isolated directory, maybe firejail could have an -I
flag
to add include paths (like the -I
C preprocessor flag). Example:
$ cat foo.profile
include bar.profile
$ firejail -I. --profile=foo.profile --include=bar.profile ./foo
This would include ./foo.profile, ./bar.profile and then run ./foo
.
This problem may be related to #3199, but it's different.
Firejail has trouble accessing a (non-existent!)
xxx.local
profile file when I run it from a folder that is mounted using gocryptfs.This works:
But this does not work -
/home/sturm/cryptmount
is an encrypted folder.Note that
qpdfview.local
does not exist anywhere. Also,qpdfview
is a random choice - any other tool that has a profile in/etc/firejail
and includes axxx.local
file shows the same behavior. For reference,/etc/firejail/qpdfview.profile
(unchanged by me) includes this line near the top:Bug and expected behavior - What did you expect to happen?
I expect to be able to run firejail from any path (including gocryptfs mounts) and see consistent outcome (and preferably no errors).
Environment