[GH-ISSUE #5640] firejail holds device mapper node preventing LUKS2/cryptsetup from being closed

gitea-mirror commented

2026-05-05 09:41:54 -06:00

Owner

Originally created by @e-pirate on GitHub (Feb 5, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5640

Description

After about 3 weeks of random guesses and attempts I finally caught firejail on holding device mapper node effectively preventing LUKS2/cryptsetup partition from been closed and completely ruining security efforts - LUKS2/cryptsetup device stays open and can be mounted as long as at least one firejail sandbox is running because your can't close it.

Steps to Reproduce

First of all it was extremely hard to figure out what is holding the device because there are no easy to use user-level instruments for this. lsof just won't do because there is no file system opened. This is very unexpected and unobvious, so initially I decided that KDE/Plasma is guilty, but after some test I found that KDE/Plasma is not the root of the problem.

Close all sandboxed applications so no firejail processes are present in system;
Open LUKS2/cryptsetup device by typing password and mount crypted filesystem:
# cryptsetup luksOpen /dev/sdxn sdxn_dmc
# mount /dev/mapper/sdxn_dmc /home/crypted
From that point sdxn_dmc device mapper node will appear and can be viewed by lsblk for example;
Run any application inside firejail sandbox, I tested with Firefox and Telegram desktop - both work same;
Unmount crypted filesystem:
# umount /home/crypted
Try to close the crypted device:
# cryptsetup close sdxn_dmc
FAIL.
Device sdxn_dmc is still in use.
But there is actually nothing that can use it - the filesystem is already unmounted.
Okey, close all application running in firejail sandboxes. Pay attention, and this is even more disturbing, the crypted device was opened and mounted by root, while firejailed applications are run by a regular user.
With no firejail processes present repeat step 5:
# cryptsetup close sdxn_dmc
Success

To prove this is firejail I repeated steps 1-5 for all application I usually run in firejail but without firejail running them "plane" and no problem with closing crypted device - everything works like expected.

Expected behavior

firejail is not affecting device mapper / LUKS2/cryptsetup devices at all, just ignore it once and forever;

Actual behavior

A single firejail process of a third-party user prevents LUKS2/cryptsetup devices from been properly closed;

Additional context

I tried to mask the disk partition and the device mapper node by enabling UDISKS_IGNORE=1 with udev rule to make udisks2 hide this devices from dbus, but this has no effect on firejail at all.

This is extremely nasty bug that ruins all the efforts of crypting file system leaving all the stuff you want to keep away from others open and accessible unless you quit all sandboxed application and retry closing the device. In my case I came across this issue while I was testing LUKS2/cryptsetup encrypted home directory with pam_mount to make user home accessible on user login and get closed as soon as user exits last session. If I login to a "crypted" user session and then start KDE/Plasma session for a different user and run any firejailed application, I then get "Device is still in use" error on "crypted" user logoff as cryptsetup can't close the crypted device. Moreover, I can't login with "crypted" user any more as pam_mount can't mount it's home. This is a major security problem because firejail will leave encrypted device open. Why? What kind of business it has with device mapper node created by a third-party user?

Environment

Gentoo linux, kernel 4.19.229
Firejail version: 0.9.64.4 and 0.9.72

Checklist

[ x] The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
[ x] I can reproduce the issue without custom modifications (e.g. globals.local).
[ x] The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
[x ] I have performed a short search for similar issues (to avoid opening a duplicate).
Some additional information can be found in cryptsetup bug tracker here.

Originally created by @e-pirate on GitHub (Feb 5, 2023). Original GitHub issue: https://github.com/netblue30/firejail/issues/5640 ### Description After about 3 weeks of random guesses and attempts I finally caught firejail on holding device mapper node effectively preventing LUKS2/cryptsetup partition from been closed and completely ruining security efforts - LUKS2/cryptsetup device stays open and can be mounted as long as at least one firejail sandbox is running because your can't close it. ### Steps to Reproduce First of all it was extremely hard to figure out what is holding the device because there are no easy to use user-level instruments for this. lsof just won't do because there is no file system opened. This is very unexpected and unobvious, so initially I decided that KDE/Plasma is guilty, but after some test I found that KDE/Plasma is not the root of the problem. 1. Close all sandboxed applications so no firejail processes are present in system; 2. Open LUKS2/cryptsetup device by typing password and mount crypted filesystem: `# cryptsetup luksOpen /dev/sdxn sdxn_dmc` `# mount /dev/mapper/sdxn_dmc /home/crypted` From that point `sdxn_dmc` device mapper node will appear and can be viewed by `lsblk` for example; 3. Run any application inside firejail sandbox, I tested with Firefox and Telegram desktop - both work same; 4. Unmount crypted filesystem: `# umount /home/crypted` 5. Try to close the crypted device: `# cryptsetup close sdxn_dmc` FAIL. `Device sdxn_dmc is still in use.` But there is actually nothing that can use it - the filesystem is already unmounted. 6. Okey, close all application running in firejail sandboxes. Pay attention, and this is even more disturbing, the crypted device was opened and mounted by root, while firejailed applications are run by a regular user. 7. With no firejail processes present repeat step 5: `# cryptsetup close sdxn_dmc` Success To prove this is firejail I repeated steps 1-5 for all application I usually run in firejail but without firejail running them "plane" and no problem with closing crypted device - everything works like expected. ### Expected behavior firejail is not affecting device mapper / LUKS2/cryptsetup devices at all, just ignore it once and forever; ### Actual behavior A single firejail process of a third-party user prevents LUKS2/cryptsetup devices from been properly closed; ### Additional context I tried to mask the disk partition and the device mapper node by enabling `UDISKS_IGNORE=1` with udev rule to make udisks2 hide this devices from dbus, but this has no effect on firejail at all. This is extremely nasty bug that ruins all the efforts of crypting file system leaving all the stuff you want to keep away from others open and accessible unless you quit all sandboxed application and retry closing the device. In my case I came across this issue while I was testing LUKS2/cryptsetup encrypted home directory with pam_mount to make user home accessible on user login and get closed as soon as user exits last session. If I login to a "crypted" user session and then start KDE/Plasma session for a different user and run any firejailed application, I then get "Device is still in use" error on "crypted" user logoff as cryptsetup can't close the crypted device. Moreover, I can't login with "crypted" user any more as pam_mount can't mount it's home. This is a major security problem because firejail will leave encrypted device open. Why? What kind of business it has with device mapper node created by a third-party user? ### Environment - Gentoo linux, kernel 4.19.229 - Firejail version: 0.9.64.4 and 0.9.72 ### Checklist - [ x] The issues is caused by firejail (i.e. running the program by path (e.g. `/usr/bin/vlc`) "fixes" it). - [ x] I can reproduce the issue without custom modifications (e.g. globals.local). - [ x] The program has a profile. (If not, request one in `https://github.com/netblue30/firejail/issues/1139`) - [x ] I have performed a short search for similar issues (to avoid opening a duplicate). Some additional information can be found in cryptsetup bug tracker [here](https://gitlab.com/cryptsetup/cryptsetup/-/issues/797).

gitea-mirror added the

bug

security

labels 2026-05-05 09:41:54 -06:00

gitea-mirror commented

2026-05-05 09:41:56 -06:00

Author

Owner

@ghost commented on GitHub (Feb 7, 2023):

Thank you for reporting this. It's a lot to take in at one go, at least it is for me. Personally I don't have that much experience with the complex coexistence of Firejail and LUKS, but I sure can understand your worries and expressed frustrations in this context. We'll need to have a deeper look at the issues involved and fix whatever is needed, hence marking this as both a 'bug' and attaching the 'security' label.

I can only hope you'll understand that at the moment I can't offer any 'do this and all your issues will be fixed' magic here.

That being said, if I understand what you're describing at all correctly, the first thoughts that sprung up while reading your report and the referenced links relate to two of Firejail's large set of options that are used to put together a sandbox:

--private-dev
Create a new /dev directory. Only disc, dri, dvb, hidraw, null, full, zero, tty, pts, ptmx, random, snd, urandom, video, log, shm and usb devices are available. Use the options --no3d, --nodvd, --nosound, --notv, --nou2f and --novideo for additional restrictions.

--deterministic-shutdown
Always shut down the sandbox after the first child has terminated. The default behavior is to keep the sandbox alive as long as it contains running processes.

The first one, --private-dev, is often used conditionally:

45a641deab/etc/profile-a-l/firefox-common.profile (L59)

What I would try is using it directly in Firefox (and in whatever other profiles you use that have the conditional. It's been my experience that doing so works fine/better if you don't need the U2F support in a specific sandbox. At least --private-dev and what it does seems to be a crucial part of your issue, so it's very much worth playing with that option IMO.

The second one, --deterministic-shutdown, doesn't get a lot of 'love' and attention in our default profiles. But it has fixed 'hanging' situations/issues before, like in ssh. Again, I can't promise it's going to be any kind of magic bullet, but I would certainly give it a go.

Potentially related: #4870, #4440, #3491, #1518

@ghost commented on GitHub (Feb 7, 2023): Thank you for reporting this. It's a lot to take in at one go, at least it is for me. Personally I don't have that much experience with the complex coexistence of Firejail and LUKS, but I sure can understand your worries and expressed frustrations in this context. We'll need to have a deeper look at the issues involved and fix whatever is needed, hence marking this as both a 'bug' and attaching the 'security' label. I can only hope you'll understand that at the moment I can't offer any 'do this and all your issues will be fixed' magic here. That being said, if I understand what you're describing at all correctly, the first thoughts that sprung up while reading your report and the referenced links relate to two of Firejail's large set of options that are used to put together a sandbox: --private-dev Create a new /dev directory. Only disc, dri, dvb, hidraw, null, full, zero, tty, pts, ptmx, random, snd, urandom, video, log, shm and usb devices are available. Use the options --no3d, --nodvd, --nosound, --notv, --nou2f and --novideo for additional restrictions. --deterministic-shutdown Always shut down the sandbox after the first child has terminated. The default behavior is to keep the sandbox alive as long as it contains running processes. The first one, `--private-dev`, is often used `conditionally`: https://github.com/netblue30/firejail/blob/45a641deaba84cb19126753f9bcfbbc14813f7c4/etc/profile-a-l/firefox-common.profile#L59 What I would try is using it directly in Firefox (and in whatever other profiles you use that have the conditional. It's been my experience that doing so works fine/better if you don't need the U2F support in a specific sandbox. At least --private-dev and what it does seems to be a crucial part of your issue, so it's very much worth playing with that option IMO. The second one, `--deterministic-shutdown`, doesn't get a lot of 'love' and attention in our default profiles. But it has fixed 'hanging' situations/issues before, like in ssh. Again, I can't promise it's going to be any kind of magic bullet, but I would certainly give it a go. Potentially related: #4870, #4440, #3491, #1518

gitea-mirror commented

2026-05-05 09:41:57 -06:00

Author

Owner

@e-pirate commented on GitHub (Feb 8, 2023):

@glitsj16 first of all thank you for your attention and time. Firejail is a complex solution and needs time and much effort to dig out and fix problems, so I don't expect this issue to be fixed in a "single pass". It is obvious this will take some time. On my side, I will make whatever it takes to help debug and fix this. I will try your advices ASAP and report back what I found. The only little problem I see is that I'm forced to stay on 0.9.64.4 because of [#5010] and [#5607].

@e-pirate commented on GitHub (Feb 8, 2023): @glitsj16 first of all thank you for your attention and time. Firejail is a complex solution and needs time and much effort to dig out and fix problems, so I don't expect this issue to be fixed in a "single pass". It is obvious this will take some time. On my side, I will make whatever it takes to help debug and fix this. I will try your advices ASAP and report back what I found. The only little problem I see is that I'm forced to stay on 0.9.64.4 because of [#5010] and [#5607].

gitea-mirror commented

2026-05-05 09:41:58 -06:00

Author

Owner

@ghost commented on GitHub (Feb 8, 2023):

@e-pirate No worries, take your time to try these options. Regarding being forced to stay on 0.9.64.4, both those issues should be fixed in git already. If it's an option for you, perhaps it's worthwhile to build firejail from git. There's detailed info on how to go about that on our wiki. In the spirit of 'everything is in constant flux and nothing stays the same', that advice could bring in other problems :) You might have noticed that we're refactoring private-etc in git (#5610) and there's bound to be some fallout at the moment... So if you decide to try git build, check out something like 252094f191, that doesn't have any of the private-etc refactor yet.

Courage!

@ghost commented on GitHub (Feb 8, 2023): @e-pirate No worries, take your time to try these options. Regarding being forced to stay on 0.9.64.4, both those issues _should_ be fixed in git already. If it's an option for you, perhaps it's worthwhile to build firejail from git. There's detailed info on how to go about that on our [wiki](https://github.com/netblue30/firejail/wiki/Using-firejail-from-git). In the spirit of 'everything is in constant flux and nothing stays the same', that advice could bring in other problems :) You might have noticed that we're refactoring `private-etc` in git (#5610) and there's bound to be some fallout at the moment... So if you decide to try git build, check out something like https://github.com/netblue30/firejail/commit/252094f191e93f33e2fcb4c1d5ae01994907224a, that doesn't have any of the private-etc refactor yet. Courage!

gitea-mirror commented

2026-05-05 09:41:59 -06:00

Author

Owner

@e-pirate commented on GitHub (Feb 8, 2023):

Just tested --private-dev like this:
firejail --private-dev firefox
And nothing changed - as long as sandbox is running I get same 'device is still in use' error, as soon as I quit sandbox and no any other sandboxes are active, I can close the crypted device.
Concerning --deterministic-shutdown - I don't think it will help because it should be possible to close crypted device during any period of sandbox life cycle regardless what's going on in the sandbox.

@e-pirate commented on GitHub (Feb 8, 2023): Just tested `--private-dev` like this: `firejail --private-dev firefox` And nothing changed - as long as sandbox is running I get same 'device is still in use' error, as soon as I quit sandbox and no any other sandboxes are active, I can close the crypted device. Concerning `--deterministic-shutdown` - I don't think it will help because it should be possible to close crypted device during any period of sandbox life cycle regardless what's going on in the sandbox.

gitea-mirror commented

2026-05-05 09:41:59 -06:00

Author

Owner

@rusty-snake commented on GitHub (Feb 9, 2023):

The first thing should be to check with --noprofile. And if that works you can start adding command. Starting with a long (redirect) profile like firefox is more complicated.

@rusty-snake commented on GitHub (Feb 9, 2023): The first thing should be to check with `--noprofile`. And if that works you can start adding command. Starting with a long (redirect) profile like firefox is more complicated.

gitea-mirror commented

2026-05-05 09:42:00 -06:00

Author

Owner

@e-pirate commented on GitHub (Feb 9, 2023):

@rusty-snake tested --noprofile with FF with no changes, crypted device is held unless I quit FF and firejail process exits.

@e-pirate commented on GitHub (Feb 9, 2023): @rusty-snake tested `--noprofile` with FF with no changes, crypted device is held unless I quit FF and firejail process exits.

gitea-mirror commented

2026-05-05 09:42:01 -06:00

Author

Owner

@rusty-snake commented on GitHub (Feb 10, 2023):

Does it happen if you only luksOpen it but do not mount it (i.e. the umount isn't propagated)?

Still testing with --noprofile.

@rusty-snake commented on GitHub (Feb 10, 2023): Does it happen if you only `luksOpen` it but do not mount it (i.e. the umount isn't propagated)? Still testing with `--noprofile`.

gitea-mirror commented

2026-05-05 09:42:01 -06:00

Author

Owner

@e-pirate commented on GitHub (Feb 13, 2023):

@rusty-snake it came out that crypted device will not be blocked if file system is not mounted, regardless if --noprofile is specified or not. I can close the crypted device even Firefox is running in active sandbox. Hope this helps to make a good assumption how to debug feather.

@e-pirate commented on GitHub (Feb 13, 2023): @rusty-snake it came out that crypted device will not be blocked if file system is not mounted, regardless if `--noprofile` is specified or not. I can close the crypted device even Firefox is running in active sandbox. Hope this helps to make a good assumption how to debug feather.

gitea-mirror commented

2026-05-05 09:42:01 -06:00

Author

Owner

@e-pirate commented on GitHub (Mar 28, 2023):

Any updates here?

@e-pirate commented on GitHub (Mar 28, 2023): Any updates here?

gitea-mirror commented

2026-05-05 09:42:02 -06:00

Author

Owner

@tetumetal commented on GitHub (Jun 15, 2023):

I'm having the same issue also in Gentoo with firejail version 0.9.72, and kernel 5.10.181-gentoo-x86_64. I wonder if anyone not using Gentoo is having the same problem.

Also, this information may be obvious but the process holding the luks is jbd2. This is how the lsof looks like when I try to close the luks device:

lsof | grep dm-3
jbd2/dm-3 14845 root cwd DIR 254,2 4096 2 /
jbd2/dm-3 14845 root rtd DIR 254,2 4096 2 /
jbd2/dm-3 14845 root txt unknown /proc/14845/exe

@tetumetal commented on GitHub (Jun 15, 2023): I'm having the same issue also in Gentoo with firejail version 0.9.72, and kernel 5.10.181-gentoo-x86_64. I wonder if anyone not using Gentoo is having the same problem. Also, this information may be obvious but the process holding the luks is **jbd2**. This is how the lsof looks like when I try to close the luks device: lsof | grep dm-3 jbd2/dm-3 14845 root cwd DIR 254,2 4096 2 / jbd2/dm-3 14845 root rtd DIR 254,2 4096 2 / jbd2/dm-3 14845 root txt unknown /proc/14845/exe

gitea-mirror commented

2026-05-05 09:42:02 -06:00

Author

Owner

@e-pirate commented on GitHub (Dec 3, 2023):

Any updates/plans here?

@e-pirate commented on GitHub (Dec 3, 2023): Any updates/plans here?

gitea-mirror commented

2026-05-05 09:42:02 -06:00

Author

Owner

@rusty-snake commented on GitHub (Dec 3, 2023):

No. No matter how often you ask there will be no update. You will be notified of any update here.

@rusty-snake commented on GitHub (Dec 3, 2023): No. No matter how often you ask there will be no update. You will be notified of any update here.

gitea-mirror commented

2026-05-05 09:42:03 -06:00

Author

Owner

@tetumetal commented on GitHub (Jan 5, 2024):

I noticed that when I'm updating a Gentoo package, in the compile phase, I experience the same issue. As far as I know, emerge also uses a sort of sandbox when updating a package. So, I guess that this issue relates to the Linux kernel's sandboxing tools, or to the specific configuration of the Linux kernel in Gentoo.

I think that it would be useful if someone tries to reproduce this issue (with firejail) in some other distro

@tetumetal commented on GitHub (Jan 5, 2024): I noticed that when I'm updating a Gentoo package, in the compile phase, I experience the same issue. As far as I know, emerge also uses a sort of sandbox when updating a package. So, I guess that this issue relates to the Linux kernel's sandboxing tools, or to the specific configuration of the Linux kernel in Gentoo. I think that it would be useful if someone tries to reproduce this issue (with firejail) in some other distro

gitea-mirror commented

2026-05-05 09:42:03 -06:00

Author

Owner

@e-pirate commented on GitHub (Jan 5, 2024):

@tetumetal what kernel version are you using? Can you give step-by-step reproduce scenario?

@e-pirate commented on GitHub (Jan 5, 2024): @tetumetal what kernel version are you using? Can you give step-by-step reproduce scenario?

gitea-mirror commented

2026-05-05 09:42:04 -06:00

Author

Owner

@tetumetal commented on GitHub (Jan 8, 2024):

I'm using the kernel 5.10.203
The step by step guide is:
1. open the luks partition and mount it somewhere
2. emerge some program (it should be something that takes time to compile)
3. During the compile phase of emerging the package (not during the configure phase, or install phase):
  A. umount the luks partition (this should work)
  B. try to close the luks partition (this should not work)
  C. cancel the compilation of the package
  D. try to close the luks partition, again (now, this should work)

@tetumetal commented on GitHub (Jan 8, 2024): - I'm using the kernel 5.10.203 - The step by step guide is: 1. open the luks partition and mount it somewhere 2. emerge some program (it should be something that takes time to compile) 3. During the ***compile*** phase of emerging the package (not during the configure phase, or install phase): A. umount the luks partition (this should work) B. try to close the luks partition (this should not work) C. cancel the compilation of the package D. try to close the luks partition, again (now, this should work)

gitea-mirror commented

2026-05-05 09:42:04 -06:00

Author

Owner

@e-pirate commented on GitHub (Jan 13, 2024):

@tetumetal thank you for the info. Currently I'm on 4.19.269 which is deprecated. I'm going to update to 6.1.67 before reproducing this potentially not related to firejail behaviour and if I can reproduce, bugreport. But before so, I need to sync old kernel config to new version and this will take some time. See what I will get in the end.

@e-pirate commented on GitHub (Jan 13, 2024): @tetumetal thank you for the info. Currently I'm on 4.19.269 which is deprecated. I'm going to update to 6.1.67 before reproducing this potentially not related to firejail behaviour and if I can reproduce, bugreport. But before so, I need to sync old kernel config to new version and this will take some time. See what I will get in the end.

gitea-mirror commented

2026-05-05 09:42:04 -06:00

Author

Owner

@schdro commented on GitHub (Sep 21, 2025):

Was also plagued by same issue. When having a separate backup shell script, which did

mounting of an external encrypted LUKS partition,
rsync copying,
and unmounting.

Always unmounting got stuck, till firejail instances were shut down.

My observation, as hint or workaround. When wrapping the script as follows, issue finally disappeared for me:

#!/bin/sh
unshare -m my-inner-backupscript.sh

This way the script will ensure that mounts of inner script are independent of the rest of the system (incl firejail).
When script ends, umount succeeded.

Of course, only some workaround, as now the victim script using LUKS mount avoids getting disturbed.

@schdro commented on GitHub (Sep 21, 2025): Was also plagued by same issue. When having a separate backup shell script, which did - mounting of an external encrypted LUKS partition, - rsync copying, - and unmounting. Always unmounting got stuck, till firejail instances were shut down. My observation, as hint or workaround. When wrapping the script as follows, issue finally disappeared for me: ```sh #!/bin/sh unshare -m my-inner-backupscript.sh ``` This way the script will ensure that `mount`s of inner script are independent of the rest of the system (incl firejail). When script ends, `umount` succeeded. Of course, only some workaround, as now the victim script using LUKS mount avoids getting disturbed.

gitea-mirror referenced this issue

2026-05-05 10:23:34 -06:00

[PR #3053] [MERGED] Add new electron-mail profile #4624

Rows
Columns

[GH-ISSUE #5640] firejail holds device mapper node preventing LUKS2/cryptsetup from being closed #3053

Description

Steps to Reproduce

Expected behavior

Actual behavior

Additional context

Environment

Checklist