github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

gshadow to be locked making useradd, userdel and gpasswd unusable. Kernel 3.10 #395

New issue

Closed

opened 2026-05-05 05:46:42 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 05:46:42 -06:00

Owner

Originally created by @ghost on GitHub (Jun 10, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/559

I'm a fan of Firejail, I was running it on Debian Testing with no issues until recently, then I switched to Centos 7.

Issue:

OS: Centos 7.2.1511, amd64

Running Firefox or Thunderbird(probably everything else) prefixed with firejail locks /etc/passwd, /etc/group and /etc/gshadow files on Centos 7 with the 3.10 kernel.

This causes some package installations to fail while firejailed applications run since plenty of them add users, like httpd, libvirt or even tcpdump. It also make adding new users, groups or adding existing users to groups impossible while firejailed applications run.

The file locks(-1 EBUSY (Device or resource busy)) errors go away if you stop or pkill firejail.

I can reproduce the issue both on the stock 3.10.0-327.el7.x86_64 and 3.10.0-327.18.2.el7.x86_64 kernels, both on real(my own laptop) and virtual machines.

Kernel 4.6.2-1.el7.elrepo.x86_64 doesn't seem to be affected.

Firejail 0.9.40 RPM was installed from one of sourceforge's mirros, linked from https://firejail.wordpress.com/download-2/.

Strace-ing useradd username will return:

rename("/etc/passwd+", "/etc/passwd") = -1 EBUSY (Device or resource busy)

Running on firejail causes selinux to generate the following in journalctl:

Jun 10 03:58:00 centos7 useradd[6092]: new group: name=rvF9PuTE, GID=1749
Jun 10 03:58:00 centos7 useradd[6092]: new user: name=rvF9PuTE, UID=1749, GID=1749, home=/home/rvF9PuTE, shell=/bin/bash
Jun 10 03:58:00 centos7 lightdm[922]: Reading profile /etc/firejail/firefox.profile
Jun 10 03:58:00 centos7 lightdm[922]: Reading profile /etc/firejail/disable-common.inc
Jun 10 03:58:00 centos7 lightdm[922]: Reading profile /etc/firejail/disable-programs.inc
Jun 10 03:58:00 centos7 lightdm[922]: Reading profile /etc/firejail/disable-devel.inc
Jun 10 03:58:00 centos7 lightdm[922]: Reading profile /etc/firejail/whitelist-common.inc
Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev proc, type proc), uses genfs_contexts
Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Jun 10 03:58:00 centos7 useradd[6092]: failure while writing changes to /etc/shadow
Jun 10 03:58:00 centos7 useradd[6092]: failed adding user 'rvF9PuTE', exit code: 1
Jun 10 03:58:00 centos7 useradd[6108]: new group: name=NPUE2CbQ, GID=1750
Jun 10 03:58:00 centos7 useradd[6108]: new user: name=NPUE2CbQ, UID=1750, GID=1750, home=/home/NPUE2CbQ, shell=/bin/bash

The issue appears regardless of selinux being on enforced, disabled or permissive mode.

The virtual machine I've tested had selinux disabled(at vultr.com), so I didn't have wrong selinux labels.

My own machine(during several reinstallations) had proper labelling since the issue both reappeared after reinstalls and I ran restorecon -R -v /etc and on /home frequently.

Relabeling the entire filesystem with /.autorelabel is irrelevant.

Linked is my Centos thread on centos.org.

https://www.centos.org/forums/viewtopic.php?f=48&t=58096

Originally created by @ghost on GitHub (Jun 10, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/559 I'm a fan of Firejail, I was running it on Debian Testing with no issues until recently, then I switched to Centos 7. Issue: OS: Centos 7.2.1511, amd64 Running Firefox or Thunderbird(probably everything else) prefixed with firejail locks /etc/passwd, /etc/group and /etc/gshadow files on Centos 7 with the 3.10 kernel. This causes some package installations to fail while firejailed applications run since plenty of them add users, like httpd, libvirt or even tcpdump. It also make adding new users, groups or adding existing users to groups impossible while firejailed applications run. The file locks(-1 EBUSY (Device or resource busy)) errors go away if you stop or pkill firejail. I can reproduce the issue both on the stock 3.10.0-327.el7.x86_64 and 3.10.0-327.18.2.el7.x86_64 kernels, both on real(my own laptop) and virtual machines. Kernel 4.6.2-1.el7.elrepo.x86_64 doesn't seem to be affected. Firejail 0.9.40 RPM was installed from one of sourceforge's mirros, linked from https://firejail.wordpress.com/download-2/. Strace-ing useradd username will return: ``` rename("/etc/passwd+", "/etc/passwd") = -1 EBUSY (Device or resource busy) ``` Running on firejail <application> causes selinux to generate the following in journalctl: ``` Jun 10 03:58:00 centos7 useradd[6092]: new group: name=rvF9PuTE, GID=1749 Jun 10 03:58:00 centos7 useradd[6092]: new user: name=rvF9PuTE, UID=1749, GID=1749, home=/home/rvF9PuTE, shell=/bin/bash Jun 10 03:58:00 centos7 lightdm[922]: Reading profile /etc/firejail/firefox.profile Jun 10 03:58:00 centos7 lightdm[922]: Reading profile /etc/firejail/disable-common.inc Jun 10 03:58:00 centos7 lightdm[922]: Reading profile /etc/firejail/disable-programs.inc Jun 10 03:58:00 centos7 lightdm[922]: Reading profile /etc/firejail/disable-devel.inc Jun 10 03:58:00 centos7 lightdm[922]: Reading profile /etc/firejail/whitelist-common.inc Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev proc, type proc), uses genfs_contexts Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Jun 10 03:58:00 centos7 kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Jun 10 03:58:00 centos7 useradd[6092]: failure while writing changes to /etc/shadow Jun 10 03:58:00 centos7 useradd[6092]: failed adding user 'rvF9PuTE', exit code: 1 Jun 10 03:58:00 centos7 useradd[6108]: new group: name=NPUE2CbQ, GID=1750 Jun 10 03:58:00 centos7 useradd[6108]: new user: name=NPUE2CbQ, UID=1750, GID=1750, home=/home/NPUE2CbQ, shell=/bin/bash ``` The issue appears regardless of selinux being on enforced, disabled or permissive mode. The virtual machine I've tested had selinux disabled(at vultr.com), so I didn't have wrong selinux labels. My own machine(during several reinstallations) had proper labelling since the issue both reappeared after reinstalls and I ran restorecon -R -v /etc and on /home frequently. Relabeling the entire filesystem with /.autorelabel is irrelevant. Linked is my Centos thread on centos.org. https://www.centos.org/forums/viewtopic.php?f=48&t=58096

gitea-mirror

2026-05-05 05:46:42 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 05:46:47 -06:00

Author

Owner

@ghost commented on GitHub (Jun 10, 2016):

It seems it doesn't matter who or which uid launches firejail.

As soon as you launch it, /etc/passwd group gshadow and shadow files become locked by firejail.

Forgot to mention, it's also not possible to change your user passwords(/etc/shadow) while a firejail process runs.

[root@vultr ~]# passwd
Changing password for user root.
New password: 
BAD PASSWORD: The password contains the user name in some form
Retype new password: 
passwd: Authentication token manipulation error

SELinux status is irrelevant. This appears on all 3 SELinux statuses.

The issue can be reproduced on any VM Centos 7.2 with 3.10 kernel.

It also happens on installing the MATE desktop, so I think DE-s are irrelevant.

What you launch doesn't need to be graphical.

Running firejail bash also locks the files mentioned above, exiting from that bash unlocks those files.

@ghost commented on GitHub (Jun 10, 2016): It seems it doesn't matter who or which uid launches firejail. As soon as you launch it, /etc/passwd group gshadow and shadow files become locked by firejail. Forgot to mention, it's also not possible to change your user passwords(/etc/shadow) while a firejail process runs. ``` [root@vultr ~]# passwd Changing password for user root. New password: BAD PASSWORD: The password contains the user name in some form Retype new password: passwd: Authentication token manipulation error ``` SELinux status is irrelevant. This appears on all 3 SELinux statuses. The issue can be reproduced on any VM Centos 7.2 with 3.10 kernel. It also happens on installing the MATE desktop, so I think DE-s are irrelevant. What you launch doesn't need to be graphical. Running firejail bash also locks the files mentioned above, exiting from that bash unlocks those files.

gitea-mirror commented

2026-05-05 05:46:49 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 10, 2016):

This is a kernel bug. If you have firejail running, you won't be able to install new packages: lots of directories such as /sbin and /usr/sbin are basically locked read-only by the kernel, and also a number of files in /etc. The problem was fixed in kernel 3.18, so if you move to 4.6.2 you shouldn't see it.

The rpm package on my download page was built and tested on Centos 7. I didn't run into any SELinux problems. What you are getting in journalctl is because of the kernel bug mentioned above.

@netblue30 commented on GitHub (Jun 10, 2016): This is a kernel bug. If you have firejail running, you won't be able to install new packages: lots of directories such as /sbin and /usr/sbin are basically locked read-only by the kernel, and also a number of files in /etc. The problem was fixed in kernel 3.18, so if you move to 4.6.2 you shouldn't see it. The rpm package on my download page was built and tested on Centos 7. I didn't run into any SELinux problems. What you are getting in journalctl is because of the kernel bug mentioned above.

gitea-mirror commented

2026-05-05 05:46:51 -06:00

Author

Owner

@ghost commented on GitHub (Jun 10, 2016):

Thanks for the explanation!

I wish I have known this before.

I've looked at quickly at the documentation and looks like only distrowatch mentions kernel 3.18 and newer(https://distrowatch.com/weekly.php?issue=20160222#tips):

The only downside I found to this feature is it requires relatively modern kernels, the system needs to be running Linux 3.18 (or newer) for the temporary file system to work.

Do you think a note can be added with a link perhaps to this issue report for other Centos 7 users with 3.10 kernels on the download page?

If you want, then we're free to close the issue.

@ghost commented on GitHub (Jun 10, 2016): Thanks for the explanation! I wish I have known this before. I've looked at quickly at the documentation and looks like only distrowatch mentions kernel 3.18 and newer(https://distrowatch.com/weekly.php?issue=20160222#tips): ``` The only downside I found to this feature is it requires relatively modern kernels, the system needs to be running Linux 3.18 (or newer) for the temporary file system to work. ``` Do you think a note can be added with a link perhaps to this issue report for other Centos 7 users with 3.10 kernels on the download page? If you want, then we're free to close the issue.

gitea-mirror commented

2026-05-05 05:46:54 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 13, 2016):

I have document it on my Known Problems page here: https://firejail.wordpress.com/support/known-problems/#removeblacklisted

@netblue30 commented on GitHub (Jun 13, 2016): I have document it on my Known Problems page here: https://firejail.wordpress.com/support/known-problems/#removeblacklisted

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#395

No description provided.

Rows
Columns