Bug 1282981 - Default permissions on /dev/shm prevent some applications from starting
Default permissions on /dev/shm prevent some applications from starting
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lukáš Nykrýn
Fedora Extras Quality Assurance
: 1289232 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2015-11-17 18:55 EST by York Possemiers
Modified: 2016-06-27 06:07 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-01-17 17:55:47 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Backtrace from attempting to start domain (2.73 KB, text/plain)
2015-11-17 18:55 EST, York Possemiers
no flags Details
journalctl since 2015-11-17 (8.23 MB, text/plain)
2015-11-22 18:20 EST, York Possemiers
no flags Details
mounts (3.40 KB, text/plain)
2015-11-23 18:45 EST, York Possemiers
no flags Details

  None (edit)
Description York Possemiers 2015-11-17 18:55:30 EST
Created attachment 1095754 [details]
Backtrace from attempting to start domain

Description of problem:
Unable to start libvirt guests in this kernel version, starts fine kernel 4.3.0-0.rc7.git0.1.fc24.x86_64. Have eliminated selinux as a culprit.

Version-Release number of selected component (if applicable):
Kernel 4.4.0-0.rc1.git0.1.fc24.x86_64

How reproducible:

Steps to Reproduce:
1. boot with listed kernel
2. use virsh start <domain>

Additional info:
Unsure how to create a domain without spice
Comment 1 York Possemiers 2015-11-17 19:58:10 EST
Bug not present in 4.4.0-0.rc0.git5.1
Comment 2 Laura Abbott 2015-11-18 17:24:47 EST
I'm able to run qemu manually and connect with spice server on -rc1. Is git5 the last of the snapshots that was working (i.e. git6 starts to fail)? Can you share your systemlogs as well?

Adding libvirt maintainers to see if they have any ideas.
Comment 3 Cole Robinson 2015-11-18 20:30:28 EST
FWIW There's a known kvm kernel regression tracked here:


But this sounds different. shm_open failing makes me think non-virt-related kernel issue
Comment 4 York Possemiers 2015-11-22 18:20 EST
Created attachment 1097552 [details]
journalctl since 2015-11-17

This is a complete dump of my logs which starts a day earlier than this bug, up until now. Unfortunately, I did not have git6 installed, so I cannot tell you whether git5 was the last one working.
Comment 5 Laura Abbott 2015-11-23 13:06:05 EST
There are a bunch of messages there about shm_open failing with permission denied so I don't think it's qemu specific. What does 'mount' look like on your system?
Comment 6 York Possemiers 2015-11-23 18:45 EST
Created attachment 1097916 [details]

I think you are right, I've just found out that google chrome fails to start with similar errors:

shm_open() failed: Permission denied
[2408:2408:1124/101443:ERROR:shared_memory_posix.cc(290)] Creating shared memory in /dev/shm/.com.google.Chrome.6sbRj4 failed: Permission denied
[2408:2408:1124/101443:ERROR:shared_memory_posix.cc(293)] Unable to access(W_OK|X_OK) /dev/shm: Permission denied
[2408:2408:1124/101443:FATAL:shared_memory_posix.cc(295)] This is frequently caused by incorrect permissions on /dev/shm.  Try 'sudo chmod 1777 /dev/shm' to fix.
Aborted (core dumped)
Comment 7 York Possemiers 2015-11-23 18:51:06 EST
So running the command suggested allows both VMs to start and google chrome to launch, but this change is only temporary. Amending title.
Comment 8 Laura Abbott 2015-11-23 19:29:09 EST
What's the output of mount? What about ls -lZd /dev/shm?
Comment 9 York Possemiers 2015-11-23 21:25:13 EST
mount is as attached previously, ls -lZd /dev/shm:
drwxr-xr-t. 2 root root system_u:object_r:tmpfs_t:s0 60 Nov 24 12:51 /dev/shm
Comment 10 Laura Abbott 2015-11-24 18:16:41 EST
Sorry,  I missed the mounts attachment. That looks okay but it looks like something is mounting /dev/shm with the wrong permissions. This isn't in the kernel but I think in systemd which is responsible  for this now a days. Moving to systemd.
Comment 11 darrell pfeifer 2015-11-30 12:55:43 EST
Not sure this is strictly a systemd problem.

The permissions issue started with the 4.4 kernels.

If I boot back to 4.2.0-1.fc24.x86_64 on the same machine the problem goes away. It returns again on a reboot to a 4.4 kernel.
Comment 12 Josh Boyer 2015-11-30 13:02:30 EST
You likely have an older systemd binary in the initramfs for 4.2.0-1.fc24.  You can probably tell by looking at the boot output for each.
Comment 13 Zbigniew Jędrzejewski-Szmek 2015-12-06 23:13:19 EST
Hm, fedora-import-state. We had some bugs previously where f-i-s would clobber permissions (#1149419), this could be something similar. Do you need f-i-s? Does the problem still occur with f-i-s disabled (systemctl mask fedora-import-state.service)?
Comment 14 Josh Boyer 2015-12-07 12:51:44 EST
*** Bug 1289232 has been marked as a duplicate of this bug. ***
Comment 15 York Possemiers 2015-12-07 18:26:46 EST
masking fedora-import-state.service does seem to fix it.
Comment 16 York Possemiers 2016-01-17 17:55:47 EST
Seems to have been fixed.
Updated to kernel 4.5.0-0.rc0.git1.1 (unsure about initscript versioning)
Comment 18 Harald Hoyer 2016-06-27 05:18:09 EDT
dracut should not create a world writable directory under /run/initramfs.
This fedora-import-state should make an exception for /dev/shm while copying state from /run/initramfs/state.
Comment 19 Harald Hoyer 2016-06-27 06:07:23 EDT
dracut patch could be reverted, if systemd had commit cacf980ed44a28e276a6cc7f8fc41f991e2ab354, which relabels /dev/shm

Note You need to log in before you can comment on or make changes to this bug.