Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: invalid --debug command line option if quiet-by-default is set in firejail.config #4168

Closed
ghost opened this issue Apr 5, 2021 · 3 comments
Labels
bug Something isn't working enhancement New feature request

Comments

@ghost
Copy link

ghost commented Apr 5, 2021

Running

$ firejail --debug git pull
Error: invalid --debug command line option

didn't work as long as quiet-by-default yes is set in the /etc/firejail/firejail.config, what is very confusing.IMHO at least the error message should be different. Something like quite-by-default is set in the configuration. I actually would love to see --debug working even if the quiet-by-default option is set to yes in the configuration.

Environment

  • Archlinux with kernel 5.10.27-1-lts
$ firejail --version
firejail version 0.9.64.4

Compile time support:
	- AppArmor support is enabled
	- AppImage support is enabled
	- chroot support is enabled
	- D-BUS proxy support is enabled
	- file and directory whitelisting support is enabled
	- file transfer support is enabled
	- firetunnel support is enabled
	- networking support is enabled
	- overlayfs support is disabled
	- private-home support is enabled
	- private-cache and tmpfs as user enabled
	- SELinux support is disabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled
@rusty-snake rusty-snake added bug Something isn't working enhancement New feature request labels Apr 5, 2021
@rusty-snake
Copy link
Collaborator

I think the only way to make --debug work with quiet is to add --debug=file (which would be nice anyway).

@ghost
Copy link
Author

ghost commented Apr 7, 2021

@rusty-snake I think this is going into the right direction of what I meant. Then I had some thoughts which arouse from working with firejai and some confusion about the messages I am confronted with. After reading through the code of src/firejail a bit and some other issues concerning quiet mode etc. I think there's a way to make messages and message handling for the end user more comprehensible and maybe solve some of the issues on the way.

I think the default (without setting anything in any profile, configuration file etc.) when you start firejail should be to show only errors. When you start firejail with --verbose you would see the usual firejail output starting with profile loading etc. This would spare the quiet settings in the profiles and the quiet-by-default setting in the config.

Errors (and maybe also information messages) from firejail should be prefixed with "firejail: " to differentiate from error messages coming from the sandboxed application. However that led me to the thought to route every message through a logger. A logger with debug, info and error levels would reflect the current level of implemented messages as far as I have seen it in the src/firejail/main.c file, but additional levels like warning etc. would be easily integratable. I see different ways to reflect a logger in the command line arguments and the configuration:

The first and obvious way would be to keep the current flags and think of them like --quiet (correlates to an inverted --error flag and error logging and suppresses error messages), --verbose (correlates to info level logging) and --debug (correlates to debug logging). Each flag should also be represented in the configuration file firejail.config with a log {error | info |debug} setting. Command line arguments overwrite the value in the configuration file. Then @rusty-snake 's proposal would make it possible to route to a file for example with --{debug | error | info}-target={file | file descriptor | syslog}[: file | file descriptor | syslog]. The default target if none is given on the command line or in the configuration could be stderr. Like shown above maybe multiple targets should be possible to route for example error output to syslog and stderr. Each of the flags should be considered as a setting of one variable log (or so), so a --debug flag on the command line would overwrite a quiet setting in the configuration file directly without the need of booleans. I think the log setting would also work within profiles. Well IMHO better than being forced to start a global profile with quiet and then you cannot overwrite quiet with ignore quiet in local profiles and so on.

The other way would be to introduce new flags --log={none | error | info | debug} and --{error | info | debug}-target{file | file descriptor | syslog}[: file | file descriptor | syslog]. To be backwards compatible , the --debug, --verbose and --quiet flags would still be kept around and map to the corresponding --log=... flag, with --quiet mapping to none and error being the default. The rest of the logic would be pretty much equivalent to the logic described in the first approach.

Please consider, that I haven't read through all of the code and am no a fluent C programmer so it's likely that I may have overseen something and please correct me if I'm wrong.

@netblue30
Copy link
Owner

Fixed! There will be more fixes there, but we track them in #4275

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature request
Projects
None yet
Development

No branches or pull requests

2 participants