Open hyiltiz opened 4 years ago
Ok, I'll try to summarize.
youtube-dl
and ffmpeg
works fine without firejailprivate-etc
and/or private-bin
for them both may resolve this issue, but unsure what (this was ongoing investigation and I am still awaiting response to my test above)libGL.so.1
seems to be the culprit in most of these cases, and it seems not only specific to ffmpeg
or youtube-dl
, as I can reproduce the same issue with okular
, despite having installing pakcages that provide libGL.so.1
x86-64
Debian but also installed i386
packages (Steam and some packages only provide a 32bit build...), and am wondering if that is the root cause. Is it possible that firejail, detecting my system as x86-64
, didn't bothered to properly mask the i386
libraries, and the x86-64
binaries accidentally found the i386
libraries when invoked with firejail which masked x86-64
? (showing okular
below as youtube-dl
calls other programs and makes debugging too complicated)
# ll /usr/lib/x86_64-linux-gnu/libGL.so.1
Permissions Size User Date Modified Name
lrwxrwxrwx 50 root 3 Nov 2020 /usr/lib/x86_64-linux-gnu/libGL.so.1 -> /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu
~# ll /usr/lib/i386-linux-gnu/libGL.so.1
Permissions Size User Date Modified Name
lrwxrwxrwx 48 root 3 Nov 2020 /usr/lib/i386-linux-gnu/libGL.so.1 -> /etc/alternatives/glx--libGL.so.1-i386-linux-gnu
# ldd /usr/bin/okular|rg libGL
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f83aecb9000)
libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f83ade49000)
libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f83ade15000)
In all cases, directly calling the program with something like /usr/bin/okular
or /usr/bin/ffmpeg
will resolve the issue, unless that command then calls another program that has a firejail profile (like youtube-dl
calls ffmpeg
which has a profile). I'd rather not throw away the firejail profiles all the time, but not sure how to work around it.
I have apparmor running, although none of the mentioned programs above are listed in aa-status
, so not sure if apparmor is relevant.
didn't bothered to properly mask the i386 libraries, and the x86-64 binaries accidentally found the i386 libraries when invoked with firejail which masked x86-64?
blacklist /usr/lib/i386-linux-gnu
(or where else debian has i386 libs) can be used to test this.
it seems some specific list in private-etc and/or private-bin for them both may resolve this issue, but unsure what (this was ongoing investigation and I am still awaiting response to my test above)
So if you add ignore private-bin
and ignore private-etc
to ffmpeg.local and youtube-dl.local it works?
So if you add
ignore private-bin
andignore private-etc
to ffmpeg.local and youtube-dl.local it works?
Yes. I'd rather not ignore them, so I think we've been bisecting a list of things to ignore above.
blacklist /usr/lib/i386-linux-gnu (or where else debian has i386 libs) can be used to test this.
Added blacklist /usr/lib/i386-linux-gnu
to okular.local
but still gives the same error message. Guess the assumption wasn't correct.
So if you add
ignore private-bin
andignore private-etc
to ffmpeg.local and youtube-dl.local it works?Yes. I'd rather not ignore them, so I think we've been bisecting a list of things to ignore above.
That right, but no narrow it down I asked if it works if they are ignored.
Assuming that adding only one of the ignores still breaks (i.e. both are necessary):
ignore private-etc
and private-bin ldconfig
work?ignore private-bin
and private-etc <ALL FILES>
?
Use unalias ls && ls /etc | tr '\n' ','
to get a list of all files/dirs. You will first get some really nothing saying error messages from firejail on files like sudoers, remove all such files until ytdl starts. If it works now, remove files from the list until you find the most minimal list which works.Regarding libblas.so, this is because "private-etc alternatives" provides now an incomplete alternatives directory (this was not the case in the past):
Native system:
$ ls -l /usr/lib/x86_64-linux-gnu/libblas.so.3
lrwxrwxrwx 1 root root 47 2. Sep 2019 /usr/lib/x86_64-linux-gnu/libblas.so.3 -> /etc/alternatives/libblas.so.3-x86_64-linux-gnu
$ ls -l /etc/alternatives/libblas.so.3-x86_64-linux-gnu
lrwxrwxrwx 1 root root 55 22. Aug 22:48 /etc/alternatives/libblas.so.3-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
$ ls -l /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
-rw-r--r-- 1 root root 399704 19. Dez 2022 /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
Inside Firejail:
$ ls -l /usr/lib/x86_64-linux-gnu/libblas.so.3
lrwxrwxrwx 1 nobody 65534 47 2. Sep 2019 /usr/lib/x86_64-linux-gnu/libblas.so.3 -> /etc/alternatives/libblas.so.3-x86_64-linux-gnu
$ LANG=C ls -l /etc/alternatives/libblas.so.3-x86_64-linux-gnu
ls: cannot access '/etc/alternatives/libblas.so.3-x86_64-linux-gnu': No such file or directory
$ ls -l /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
-rw-r--r-- 1 nobody 65534 399704 19. Dez 2022 /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
Same issue with wine executables:
Native system:
$ ls -l /usr/bin/wine
lrwxrwxrwx 1 root root 22 18. Feb 2023 /usr/bin/wine -> /etc/alternatives/wine
$ ls -l /etc/alternatives/wine
lrwxrwxrwx 1 root root 20 18. Feb 2023 /etc/alternatives/wine -> /usr/bin/wine-stable
$ ls -l /usr/bin/wine-stable
-rwxr-xr-x 1 root root 1029 18. Feb 2023 /usr/bin/wine-stable
Inside Firejail:
$ ls -l /usr/bin/wine
lrwxrwxrwx 1 nobody 65534 22 18. Feb 2023 /usr/bin/wine -> /etc/alternatives/wine
$ LANG=C ls -l /etc/alternatives/wine
ls: cannot access '/etc/alternatives/wine': No such file or directory
$ ls -l /usr/bin/wine-stable
-rwxr-xr-x 1 nobody 65534 1029 18. Feb 2023 /usr/bin/wine-stable
For some reason /etc/alternatives is incomplete with "private-etc alternatives". Some links are still available, others are missing. I can see no good reason why symlinks to installed software are "randomly" removed.
This affects Debian Bookworm, firejail 0.9.72.
Regarding libblas.so, this is because "private-etc alternatives" provides now an incomplete alternatives directory (this was not the case in the past):
This may potentially be fixed by:
Write clear, concise and in textual form.
Bug and expected behavior
youtube-dl -x SOMELINK
fails.youtube-dl -x SOMELINK
succeeds.No profile or disabling firejail
firejail --noprofile ffprobe SOMEFILE
succeeds./usr/bin/ffprobe SOMEFILE
succeeds.Reproduce Steps to reproduce the behavior:
firejail youtube-dl -x SOMELINK
orfirejail ffprobe SOMEFILE
Environment
lsb_release -a
)firejail --version
) exclusive or used git commit (git rev-parse HEAD
)Compile time support:
Checklist
find / -name 'firejail' 2>/dev/null
/fd firejail
to locate profiles ie in/usr/local/etc/firejail/PROGRAM.profile
)BTW, I just noticed that the above
firejail --debug
provided way too much information about my filesystem and setup. Was that necessary? If so, please consider creating a key pair and uploading your public key so these kinds of probably sensitive private information can be shared directly with the project without putting it up in the Internet indefinitely in plain text.