mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #2874] Write to console error message when trying to rename a whitelisted file #1797
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#1797
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 @crass on GitHub (Jul 27, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2874
Since the issue where rename fails on whitelisted files is somewhat common. I suggest that we try to actively notify the user when this issue is triggered. I think we can actively enable this notification only for selected profiles by adding a config option (eg.
notify-rename-whitelist).For such profiles, we could hook
renamewithLD_PRELOADlibrary. When arenamefails withEBUSY, check that the file is a mountpoint, and then write to the console a glaring message saying something to the effect that this is a known issue and to go to a url in our wiki explaining the issue and potential work arounds.For extra points, we could detect that a program is a graphical one and also popup the message in a popup box (using our own custom program or something like xmessage, but prettier, on the host system).
Using
LD_PRELOADwon't work for programs that bypass glibc for syscalls, but I'd expect that to be a rare situation.For reference, see:
@Vincent43 commented on GitHub (Jul 27, 2019):
Why not add this into
whitelistoption?@netblue30 commented on GitHub (Jul 31, 2019):
I would say let's try it out. We are already doing something similar to LD_PRELOAD for --trace and --tracelog. Also seccomp ends up there in some cases.
It's not a pure LD_PRELOAD, more like a global one based on /etc/ld.preload file. So we generate a new /etc/ld.preload file and we place in it some of our libraries (src/libtrace, src/libtracelog, src/libpostexec). When the sandboxed program starts, it will load the .so libraries. The code to build the new /etc/ld.preload is in fs_trace,c.