Bug 847336

Summary:	systemd-tmpfiles fails to create directories under /var/lock (aka /run/lock)
Product:	[Fedora] Fedora	Reporter:	John W. Linville <linville>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	17	CC:	johannbg, lnykryn, metherid, mschmidt, msekleta, notting, plautrba, systemd-maint, vpavlin
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-08-14 17:08: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:

Description John W. Linville 2012-08-10 15:19:29 UTC

# systemctl status systemd-tmpfiles-setup.service
systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories
	  Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static)
	  Active: active (exited) since Fri, 10 Aug 2012 10:03:08 -0400; 1h 8min ago
	    Docs: man:tmpfiles.d(5)
	 Process: 6731 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/systemd-tmpfiles-setup.service

Aug 10 10:03:08 linville-8530p.local systemd-tmpfiles[6731]: Failed to create directory /var/lock/lvm: Permission denied
Aug 10 10:03:08 linville-8530p.local systemd-tmpfiles[6731]: Failed to create directory /var/lock/ppp: Permission denied
Aug 10 10:03:08 linville-8530p.local systemd-tmpfiles[6731]: Failed to create directory /var/lock/uucp: Permission denied

'grep lock /var/log/audit/audit.log | grep -v success' gives no output, so I don't think this is an SElinux issue.

Manually running '/usr/bin/systemd-tmpfiles --create' as root creates the directories as expected.  After that, at least the uucp bits function normally.

Comment 1 Michal Schmidt 2012-08-10 15:23:56 UTC

> 'grep lock /var/log/audit/audit.log | grep -v success' gives no output, so I
> don't think this is an SElinux issue.

John,
I'm not sure this command can definitely rule SELinux out. Could you confirm that by booting with "enforcing=0" on the kernel command line?

Comment 2 John W. Linville 2012-08-10 16:10:57 UTC

OK, that does seem to let the systemd-tmpfiles service succeed.  I have no idea why the previous failures showed no trace in the audit.log...?  I thought my days of disabling SElinux were over...

So, how to fix this without disabling SElinux?

Comment 3 Michal Schmidt 2012-08-11 06:29:32 UTC

The denials may occur before auditd starts. In that case you'd find them in dmesg.

This is how the relevant files are labeled on my system. Please compare with yours:

$ ls -Zd /var /var/lock /run /run/lock /usr/bin/systemd-tmpfiles
drwxr-xr-x. root root system_u:object_r:var_run_t:s0   /run
drwxr-xr-x. root root system_u:object_r:var_lock_t:s0  /run/lock
-rwxr-xr-x. root root system_u:object_r:systemd_tmpfiles_exec_t:s0 /usr/bin/systemd-tmpfiles
drwxr-xr-x. root root system_u:object_r:var_t:s0       /var
lrwxrwxrwx. root root system_u:object_r:var_lock_t:s0  /var/lock -> ../run/lock

Comment 4 John W. Linville 2012-08-13 13:46:58 UTC

Label on /var/lock is different...

$ ls -Zd /var /var/lock /run /run/lock /usr/bin/systemd-tmpfiles 
drwxr-xr-x. root root system_u:object_r:var_run_t:s0   /run
drwxr-xr-x. root root system_u:object_r:var_lock_t:s0  /run/lock
-rwxr-xr-x. root root system_u:object_r:systemd_tmpfiles_exec_t:s0 /usr/bin/systemd-tmpfiles
drwxr-xr-x. root root system_u:object_r:var_t:s0       /var
lrwxrwxrwx. root root system_u:object_r:var_t:s0       /var/lock -> ../run/lock

Comment 5 Michal Schmidt 2012-08-13 14:01:35 UTC

Does "restorecon -v /var/lock" fix the label and the problem?

Comment 6 John W. Linville 2012-08-14 17:08:47 UTC

Michal, sorry for the late reply -- I didn't want to reboot during the day yesterday...

Yes, the relabel of that link does the trick.  I have no idea how it got mislabeled or whatnot.  Anyway, thanks.