mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #4815] firejail --list truncates command output in pipes and command substitutions #2785
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#2785
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 @cyriax0 on GitHub (Jan 3, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4815
Description
firejail --listtruncates output depending on console size / terminal size, making it's behaviour in scripts non-consistent.x=$(firejail --list);echo $xshould return untruncated output).firejail --list|catshould return untruncated output).for an example on how I'd expect it to work compare the output of
ps ax,x=$(ps ax);echo $xandps ax|catSteps to Reproduce
Expected behavior
firejail --listshould always print the full command when used in pipes or command substitutions.firejail --listshould not be dependend on console size when used in pipes or command substitutions.Actual behavior
firejail --listdid not show the full command, even if attached to a pipe or in a script.firejail --list | grep foobarmight not find the program/really/long/path/to/foobar.x=$(firejail --list)contains truncated output.Additional context
This issue is especially relevant to working in the console or running scripts.
In my case I was writing a script looping over the output with
IFS=$'\n';for started_jail in $(firejail --list);dowhich did not show the programs as expected. Took a while to debug that inconsitent behavior and find a solution for scripting. The dependence on console size of my scripts output which was not directly the firejail output but tried to parse it anyway, was especially confusing.Quick and Dirty Fix for Scripting (until the issue might be fixed)
If you're writing a script instead of
$(firejail --list)orfirejail --list|foobaruse$(echo|firejail --list)andecho|firejail --list|foobar. Firejail decides on the output width by the width of it's stdin instead of stdout. If it's stdin is attached to a pipe instead of a terminal it has no width, so it defaults to arbitrary wide output.Environment
Checklist
Most of this checklist does not apply as it's not an error with a wrapped program.
@cyriax0 commented on GitHub (Jan 3, 2022):
Closed issue #98 seems related at first glance, but isn't (the issue there were encoding problems).
@cyriax0 commented on GitHub (Jan 3, 2022):
As far as I can see, the dependency on only stdin is in src/lib/pid.c at the start of the
print_elemfunction.@rusty-snake commented on GitHub (Jan 3, 2022):
I can not reproduce:
Command:
firejail read -- "$(for _ in {0..4000}; do echo -n a; done)"(length > 4000)Can you try a newer firejail version.
@cyriax0 commented on GitHub (Jan 8, 2022):
On Archlinux with firejail 0.9.66 it's not an issue anymore. - Damn you Debian.
Sorry for the inconvenience.