mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #5367] discord: when not using firecfg, launching discord from CLI is prone to failure #2973
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#2973
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 @ghost on GitHub (Sep 13, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5367
A user on our IRC channel (rahl-) brought to our attention that due to the multiple naming used in our discord profiles things can break rather easily, leaving users in a confused state.
$ firejail /opt/discord/Discord
We can improve the profiles to catch these kind of situations and avoid future issues/questions from our users. I'll be opening a PR on this shortly. But we need to look at implementing a safe and reliable way to open URLs in whatever web browser the user is using, which is currently still broken. This relates to the below and probably many others:
@rahlhar commented on GitHub (Sep 14, 2022):
Some reference background
The
Archpackage installs the binary at/opt/discord/Discordand providesa symlink at
/usr/bin/discord.Using
firejail discordexplicitly after installation behaves as expected, asseen in the paste that glitsj16 included.
The problem arose when creating a shell script to make sure
discordis alwaysrun in this fashion.
Solution
The solution for me at time of writing was to force use of the "discord" profile,
rather than "Discord", and to call the binary directly.
Thanks to glitsj16 et al at
#firejail.Another (related?) problem
I further asked how I might monitor the
discordapp to get a better idea ofwhat it gets up to. glitsj16 advised the following:
--trace[=filename]optiontracelogoption; this is disabled bydefault in /etc/firejail/firejail.config so you'd need to enable it there +
add --tracelog (CLI) or tracelog to your discord profile (i think the latter
would be easier if you want to play with/test different options)
that's anice way to get notified on firejail sandbox violations in general
As yet, I have only tried the first suggestion. Unfortunately this lead to
another, perhaps related problem. Unless it becomes clear that this should be
filed as a separate issue, I'll post here.
Trying suggestion
1.simply results in a hang before the child process getsspawned; after this line is output, nothing happens:
To be absolutely certain, I also tested without using the script stub, but the
problem stands.
Also, the trace file is created, but never written to.
It was suggested to try with
--ignore=private-binbut it had no effect.