Bug 1282981

Summary: Default permissions on /dev/shm prevent some applications from starting
Product: [Fedora] Fedora Reporter: York Possemiers <ypossem>
Component: initscriptsAssignee: Lukáš Nykrýn <lnykryn>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: awilliam, crobinso, darrellpf, gansalmon, harald, itamar, johannbg, jonathan, kernel-maint, labbott, libvirt-maint, lnykryn, madhu.chinakonda, mchehab, msekleta, npmccallum, s, systemd-maint, ypossem, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-17 22:55:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Backtrace from attempting to start domain
none
journalctl since 2015-11-17
none
mounts none

Description York Possemiers 2015-11-17 23:55:30 UTC
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
spice-server-0.12.6-1.fc24.x86_64
libvirt-daemon-kvm-1.2.21-1.fc24.x86_64


How reproducible:
100%

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-18 00:58:10 UTC
Bug not present in 4.4.0-0.rc0.git5.1

Comment 2 Laura Abbott 2015-11-18 22:24:47 UTC
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-19 01:30:28 UTC
FWIW There's a known kvm kernel regression tracked here:

https://bugzilla.redhat.com/show_bug.cgi?id=1278688

But this sounds different. shm_open failing makes me think non-virt-related kernel issue

Comment 4 York Possemiers 2015-11-22 23:20:49 UTC
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 18:06:05 UTC
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 23:45:00 UTC
Created attachment 1097916 [details]
mounts

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 23:51:06 UTC
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-24 00:29:09 UTC
What's the output of mount? What about ls -lZd /dev/shm?

Comment 9 York Possemiers 2015-11-24 02:25:13 UTC
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 23:16:41 UTC
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 17:55:43 UTC
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 18:02:30 UTC
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-07 04:13:19 UTC
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 17:51:44 UTC
*** Bug 1289232 has been marked as a duplicate of this bug. ***

Comment 15 York Possemiers 2015-12-07 23:26:46 UTC
masking fedora-import-state.service does seem to fix it.

Comment 16 York Possemiers 2016-01-17 22:55:47 UTC
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 09:18:09 UTC
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 10:07:23 UTC
dracut patch could be reverted, if systemd had commit cacf980ed44a28e276a6cc7f8fc41f991e2ab354, which relabels /dev/shm