Closed mqudsi closed 5 years ago
I don't think WSL actually implements any of the kernel features that firejail needs, because it isn't actually running the Linux kernel.
That being said the error message should probably be tweaked for different cases like this.
While I highly doubt WSL implements the needed kernel container APIs, as far as I can tell, firejail doesn't actually check for the APIs. It first checks the "container" envvar (see check_namespace_virt
) and if not in a container white list, checks if its in a pid namespace by seeing if any of a list of 5 kernel process names exist in /proc (see check_kernel_procs
). I suspect firejail isn't finding a matching kernel process name. If you run with --debug
, I believe more info confirming this will be shown.
This seems list a pretty hacky/error-prone way of doing this, but I'm not terribly interested in this use case, especially since the underlying APIs likely aren't there anyway.
Let's go ahead and close this as wontfix for now (although apparently WSL 2 will actually run a Linux kernel? That may very well change the situation).
To anyone reading this, WSL 2 doesn't work either. At least the 19041 build.
Hey sorry to bump this old issue but I've compiled a custom kernel with everything needed for firejail, apparmor, selinux, etc and now running into this, is there any workaround for this?
Try to start with container=lxc
.
Try to start with
container=lxc
.
Yep that works! Although now running into a weird issue where it takes like over 60 seconds to launch if I give it a profile, --noprofile is instant, will look into that. Thanks though!
I'm unable to use firejail (to test for app compatibility) due to it always thinking it's running in a sandbox anytime I run it under WSL.