[GH-ISSUE #3135] Concise command output for documentation purpose

gitea-mirror commented

2026-05-05 08:37:48 -06:00

Owner

Originally created by @Ricky-Tigg on GitHub (Jan 9, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3135

Using Linux, I attempt to document relevant functions I use into my project: firejail --version is one of them.

Enhancement suggestion: concise commands output:s

Current output:

$ firejail --version
firejail version 0.9.57

Compile time support:
	- AppArmor support is disabled
	- AppImage support is enabled
	- chroot support is enabled
	- file and directory whitelisting support is enabled
	- file transfer support is enabled
	- networking support is enabled
	- overlayfs support is enabled
	- private-home support is enabled
	- seccomp-bpf support is enabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

$

Concise output 1:

$ firejail --version
firejail version 0.9.57 (<release_date>)

Compile time support:
 Disabled supports:
- AppArmor
 Enabled supports:
- AppImage 
- chroot 
- file and directory whitelisting 
- file transfer 
- networking 
- overlayfs 
- private-home 
- seccomp-bpf 
- user namespace 
- X11 sandboxing 
$

Concise output 2:

$ firejail --version
firejail version 0.9.57 (<release_date>)

Compile time support:
 Disabled supports: AppArmor
 Enabled supports: AppImage – chroot – file and directory whitelisting – file transfer – networking – overlayfs – private-home – seccomp-bpf – user namespace 
- X11 sandboxing 
$

Mention Wayland sandboxing is not present; would this mean that Wayland server is not detected thus not part of the compile time support?

Originally created by @Ricky-Tigg on GitHub (Jan 9, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3135 Using Linux, I attempt to document relevant functions I use into my project: `firejail --version` is one of them. Enhancement suggestion: concise commands output:s - Current output: ``` $ firejail --version firejail version 0.9.57 Compile time support: - AppArmor support is disabled - AppImage support is enabled - chroot support is enabled - file and directory whitelisting support is enabled - file transfer support is enabled - networking support is enabled - overlayfs support is enabled - private-home support is enabled - seccomp-bpf support is enabled - user namespace support is enabled - X11 sandboxing support is enabled $ ``` - Concise output 1: ``` $ firejail --version firejail version 0.9.57 (<release_date>) Compile time support: Disabled supports: - AppArmor Enabled supports: - AppImage - chroot - file and directory whitelisting - file transfer - networking - overlayfs - private-home - seccomp-bpf - user namespace - X11 sandboxing $ ``` - Concise output 2: ``` $ firejail --version firejail version 0.9.57 (<release_date>) Compile time support: Disabled supports: AppArmor Enabled supports: AppImage – chroot – file and directory whitelisting – file transfer – networking – overlayfs – private-home – seccomp-bpf – user namespace - X11 sandboxing $ ``` Mention `Wayland sandboxing` is not present; would this mean that Wayland server is not detected thus not part of the compile time support?

gitea-mirror closed this issue

2026-05-05 08:37:49 -06:00

gitea-mirror commented

2026-05-05 08:37:50 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 9, 2020):

Mention Wayland sandboxing is not present; would this mean that Wayland server is not detected thus not part of the compile time support?

Wayland is sandboxed by design.

@rusty-snake commented on GitHub (Jan 9, 2020): > Mention `Wayland sandboxing` is not present; would this mean that Wayland server is not detected thus not part of the compile time support? Wayland is sandboxed by design.

gitea-mirror commented

2026-05-05 08:37:51 -06:00

Author

Owner

@Ricky-Tigg commented on GitHub (Jan 10, 2020):

On operating systems, such as Fedora, Red Hat, and Centos, Apparmor's counterpart, SELinux, does operate. Thus a mention related to support status regarding AppArmor is irrelevant then its presence as output appropriately not needed.. This is a suitable target for an enhancement

@Ricky-Tigg commented on GitHub (Jan 10, 2020): On operating systems, such as Fedora, Red Hat, and Centos, Apparmor's counterpart, SELinux, does operate. Thus a mention related to support status regarding AppArmor is irrelevant then its presence as output appropriately not needed.. This is a suitable target for an enhancement

gitea-mirror commented

2026-05-05 08:37:52 -06:00

Author

Owner

@Vincent43 commented on GitHub (Jan 10, 2020):

This is information if apparmor support was enabled during compiling firejail not if system had apparmor support.

@Vincent43 commented on GitHub (Jan 10, 2020): This is information if apparmor support was enabled during compiling firejail not if system had apparmor support.

gitea-mirror commented

2026-05-05 08:37:53 -06:00

Author

Owner

@Ricky-Tigg commented on GitHub (Jan 13, 2020):

Hey. Afterwards, I realise that "Compile time support:" was certainly explicit enough; I then interpreted it wrong since I understood it as follow: listed components that may be supported in user's OS will have either support or not in firejail commands. Is it then so that a component whose support was enabled during Firejail compile time will be supported as well in user's OS?

There is indeed no apprmor component on my system and appimage is supported. Are those cases then coincidences?

$ dnf -q repoquery --archlist noarch,x86_64 list *apparmor*

$ firejail --appimage --private --noprofile ./arduino
Mounting appimage type 1
Parent pid 2958, child pid 2961

**     Warning: dropping all Linux capabilities     **
[...]

What could be then the context in firejail command lines regard Apparmor on Open(SUSE) systems , since those systems do have support for Apparmor?

@Ricky-Tigg commented on GitHub (Jan 13, 2020): Hey. Afterwards, I realise that "Compile time support:" was certainly explicit enough; I then interpreted it wrong since I understood it as follow: listed components that may be supported in user's OS will have either support or not in firejail commands. Is it then so that a component whose support was enabled during Firejail compile time will be supported as well in user's OS? There is indeed no apprmor component on my system and appimage is supported. Are those cases then coincidences? ``` $ dnf -q repoquery --archlist noarch,x86_64 list *apparmor* $ firejail --appimage --private --noprofile ./arduino Mounting appimage type 1 Parent pid 2958, child pid 2961 ** Warning: dropping all Linux capabilities ** [...] ``` What could be then the context in firejail command lines regard Apparmor on Open(SUSE) systems , since those systems do have support for Apparmor?

gitea-mirror commented

2026-05-05 08:37:53 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 13, 2020):

There is indeed no apprmor component on my system and appimage is supported. Are those cases then coincidences?

Apparmor and appimage have absolutely no relation to each other (except that both are for linux)

@rusty-snake commented on GitHub (Jan 13, 2020): > There is indeed no apprmor component on my system and appimage is supported. Are those cases then coincidences? Apparmor and appimage have absolutely no relation to each other (except that both are for linux)

gitea-mirror commented

2026-05-05 08:37:54 -06:00

Author

Owner

@Vincent43 commented on GitHub (Jan 13, 2020):

I then interpreted it wrong since I understood it as follow: listed components that may be supported in user's OS will have either support or not in firejail commands. Is it then so that a component whose support was enabled during Firejail compile time will be supported as well in user's OS?

firejail --version doesn't show what user OS support. You can run firejail --version for the same binary on fedora and opensuse and the output will be the same.

@Vincent43 commented on GitHub (Jan 13, 2020): > I then interpreted it wrong since I understood it as follow: listed components that may be supported in user's OS will have either support or not in firejail commands. Is it then so that a component whose support was enabled during Firejail compile time will be supported as well in user's OS? `firejail --version` doesn't show what user OS support. You can run `firejail --version` for the same binary on fedora and opensuse and the output will be the same.

gitea-mirror commented

2026-05-05 08:37:55 -06:00

Author

Owner

@Ricky-Tigg commented on GitHub (Jan 13, 2020):

to rusty-snake – Sure; However I meant regards to that firejail --version output

   - AppArmor support is disabled
   - AppImage support is enabled

to Vincent43 – i understand the command. at last.

The _manual page_s would certainly benefit from this elaborated information.

@Ricky-Tigg commented on GitHub (Jan 13, 2020): to _rusty-snake_ – Sure; However I meant regards to that `firejail --version` output ``` - AppArmor support is disabled - AppImage support is enabled ``` to _Vincent43_ – i understand the command. at last. The _manual page_s would certainly benefit from this elaborated information.

Rows
Columns

[GH-ISSUE #3135] Concise command output for documentation purpose #1966