mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #863] private-bin: use actual files instead of symbolic links #588
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#588
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 @GabrielH0we on GitHub (Oct 17, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/863
Trying to run winetricks and wine under Slackware with private-bin. (firejail-0.9.44-rc1)
I have serveral symbolic links in /usr/bin folder, which lead to actual executables in /bin folder.
Winetricks with firejail doesn't want to run symbolic links. It asks for actual files.
So, I didn't only need to add all required executables to private-bin, but I also needed to remove all symbolic links for those executables from /usr/bin folder and replace them with actual files.
Like
rm /usr/bin/which && cp /bin/which /usr/bin/whichOnly after that I could successfully run
firejail winetricks list-installedIt looks like firejail problem, because if added to private-bin file in /usr/bin folder is not executable, winetricks doesn't have any problems with it.
My current private-bin config is
@chiraag-nataraj commented on GitHub (Oct 17, 2016):
Can you provide the actual output from Winetricks? It seems like a Winetricks-specific problem since LibreOffice also uses a symlink (to a binary in
/usr/lib) and it works fine. It would also seem that since the symlinks and binaries have the same name, firejail is getting confused when scanning for files to add toprivate-bin(since both/binand/usr/binare in the scan path).@GabrielH0we commented on GitHub (Oct 17, 2016):
Here is what I see after
Same with --debug
@chiraag-nataraj commented on GitHub (Oct 17, 2016):
Hmmm...I see. So, for example, here's my output of
ls -lh /usr/bin/libreoffice:and here's my output of
ls -lh /usr/bin/whichand here's the relevant section of my (debug) output when I append
whichto theprivate-binof mylibreofficeprofile:Do
/bin/dirnameand/bin/sha1sumexist on your machine? Which version of firejail are you using?@GabrielH0we commented on GitHub (Oct 17, 2016):
Its 0.9.44-rc1.
/bin/dirnameand/bin/sha1sumdo exist on my machine.But it's not about files in
/bin. It's about symlinks in/usr/binto files in/bin. After I replace symlinks in/usr/binwith files from/binwinetricks have no problem running.@chiraag-nataraj commented on GitHub (Oct 17, 2016):
So the interesting thing is that when I did that with
which(in my example), firejail had no problem. Can you post your full profile (please attach as a txt file) so that this is easier to debug?@GabrielH0we commented on GitHub (Oct 18, 2016):
Current winetricks profile.
winetricks.txt
@chiraag-nataraj commented on GitHub (Oct 18, 2016):
Huh, so okay. It's interesting - basically, I think my first intuition was right. If you load up a shell (
shis fine) and whitelistls(so you can examine the directory), you will see that/bin/whichpoints to.../bin/which. That obviously is a bit of a problem and is the root cause of what you are seeing. Let me experiment a bit and update this comment.[Edit] Huh. @netblue30, this would seem to be a bug of sorts. Basically, whitelisting a binary that is a symlink to another directory included in the
private-binpath leads to a circular symlink without actual access to the binary.@Khady commented on GitHub (Feb 7, 2017):
Hi. I'm facing this issue too. I see that this issue is closed, but there is no explanation. Is there a fix?
@netblue30 commented on GitHub (Feb 8, 2017):
I would say open a new bug. I don't remember what was the fix here.