mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3119] Strange pathname behaviour #1956
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#1956
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 @adrianlshaw on GitHub (Jan 3, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3119
I've been trying to sandbox an application that looks for a file in
${HOME}.local/foobar/. Without any sandbox it finds the file.But within firejail (private-etc enabled in the profile and file path whitelisted) the application itself says it can't find the file in
/.local/foobar/. Yes, that's a leading slash. It genuinely has no business looking for filenames in the root directory, so somewhere there must be a bug that misses out the "home/username" part of the path.I'm unsure if this is a bug in the application or with firejail. Am I missing something obvious?
@rusty-snake commented on GitHub (Jan 3, 2020):
Which applications? Also with --noprofile?
Probably a bug the applications that occurs inside firejail because of some environment changes.
@adrianlshaw commented on GitHub (Jan 4, 2020):
It's the "barrier" program. I've been further hardening it by giving its own private etc and limiting access to the home directory. I have the rules ready but this issue is stopping progress and it's a peculiar one.
Adding a dodgy symlink to the root filesystem sadly does make it work, but isn't a good solution. Firejail isn't (and probably shouldn't be) in the business of setting up symlinks in private filesystems. Guess the next step is for me to look through the barrier source code.
@rusty-snake commented on GitHub (Feb 10, 2020):
still an issue?
@adrianlshaw commented on GitHub (Feb 11, 2020):
Not made any progress. Closing for now until I can confirm if it's a firejail issue.
@Vincent43 commented on GitHub (Feb 11, 2020):
Did you tried without
private-etcand/or whitelisted home or even with--noprofile?