Bug 836644

Creating a clone for F16, as requested in bug 806369.

+++ This bug was initially created as a clone of Bug #806369 +++

Description of problem:

When a filesystem check is forced on boot using /forcefsck, once the filesystem check is completed, the /forcefsck file should be removed, but it isn't

Version-Release number of selected component (if applicable):

systemd 44-1 fc17 

and

systemd 37-17 fc16

How reproducible:

touch /forcefsck
reboot

Steps to Reproduce:
1. touch /forcefsck
2. reboot
3. the /forcefsck file still exists after the filesystem check completes and the system boots.
  
Actual results:

/forcefsck file remains after filesystem check completed 


Expected results:

/forcefsck file should be removed once filesystem check completes

Additional info:

By not removing the /forcefsck file, then a filesystem check will be forced upon every boot until the file is manually removed. This is not proper behaviour, especially on systems with large filesystems that take a long time to check. 

This is occurring on Fedora 17, and Fedora 16.

--- Additional comment from mschmidt on 2012-03-23 11:22:23 EDT ---

I'd expect /forcefsck to be removed by systemd-tmpfiles-setup.service. There is a directive for it in /usr/lib/tmpfiles.d/systemd.conf.

Does "systemctl --failed" report any problems after boot?

--- Additional comment from danielbelton on 2012-03-23 11:36:07 EDT ---

not a single one reported. No errors found in any of the logs either. 

[root@tower20 etc]# systemctl --failed
UNIT LOAD   ACTIVE SUB JOB DESCRIPTION

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

0 units listed. Pass --all to see inactive units, too.


Also, here is what is in my /usr/lib/tmpfiles.d/systemd.conf

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.

# See tmpfiles.d(5) for details

d /run/user 0755 root root 10d
F /run/utmp 0664 root utmp -

f /var/log/wtmp 0664 root utmp -
f /var/log/btmp 0600 root utmp -

d /var/cache/man - - - 30d

r /forcefsck
r /forcequotacheck
r /fastboot

d /run/systemd/ask-password 0755 root root -
d /run/systemd/seats 0755 root root -
d /run/systemd/sessions 0755 root root -
d /run/systemd/users 0755 root root -

--- Additional comment from danielbelton on 2012-03-23 11:41:26 EDT ---

well, look what I found..

[root@tower20 tmpfiles.d]# 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, 23 Mar 2012 09:53:34 -0500; 46min ago
	 Process: 515 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/systemd-tmpfiles-setup.service

Mar 23 09:53:34 tower20.home systemd-tmpfile[515]: Successfully loaded SELinu...
Mar 23 09:53:34 tower20.home systemd-tmpfile[515]: remove(/forcefsck): Permis...
[root@tower20 tmpfiles.d]# 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, 23 Mar 2012 09:53:34 -0500; 47min ago
	 Process: 515 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/systemd-tmpfiles-setup.service

Mar 23 09:53:34 tower20.home systemd-tmpfile[515]: Successfully loaded SELinux database in 18ms 43us, size on heap is 525K.
Mar 23 09:53:34 tower20.home systemd-tmpfile[515]: remove(/forcefsck): Permission denied

--- Additional comment from mschmidt on 2012-03-23 11:45:22 EDT ---

(In reply to comment #3)
> well, look what I found..
> 
> [root@tower20 tmpfiles.d]# systemctl status systemd-tmpfiles-setup.service
...
> Mar 23 09:53:34 tower20.home systemd-tmpfile[515]: Successfully loaded SELinux
> database in 18ms 43us, size on heap is 525K.
> Mar 23 09:53:34 tower20.home systemd-tmpfile[515]: remove(/forcefsck):
> Permission denied

Nice!
It runs as root, so the denial is likely due to SELinux. What context does the file have?: ls -lZ /forcefsck
Do you have any AVC denials logged?: ausearch -m avc -ts today

--- Additional comment from danielbelton on 2012-03-23 11:48:19 EDT ---

[root@tower20 tmpfiles.d]# ls -lZ /forcefsck
-rw-r--r--. root root unconfined_u:object_r:etc_runtime_t:s0 /forcefsck


Looks like no AVC denials logged, though..

[root@tower20 tmpfiles.d]# ausearch -m avc -ts today
<no matches>

--- Additional comment from mschmidt on 2012-03-23 12:19:17 EDT ---

The AVC message could be in dmesg:
dmesg|grep -i avc

--- Additional comment from danielbelton on 2012-03-23 12:21:23 EDT ---

yes, I do get one there.

[root@tower20 /]# dmesg | grep avc
[   46.540924] type=1400 audit(1332514414.367:4): avc:  denied  { write } for  pid=515 comm="systemd-tmpfile" name="/" dev="sda5" ino=2 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir

--- Additional comment from mschmidt on 2012-03-23 12:25:41 EDT ---

Reassigning to selinux-policy.
Please allow systemd-tmpfiles to delete files in the root directory.

--- Additional comment from danielbelton on 2012-03-23 12:28:05 EDT ---

Thanks Michal for your very prompt response to this and all of your help in tracing the bug down :)

--- Additional comment from mgrepl on 2012-03-26 09:49:56 EDT ---

So systemd-tmpfiles removes 

/forcefsck
/forcequotacheck
/fastboot

which means it would allow systemd_tmpfiles_t to remove files in the root directory.

--- Additional comment from mgrepl on 2012-03-26 09:51:34 EDT ---

Are these files created only by a user?

--- Additional comment from notting on 2012-03-26 11:27:04 EDT ---

They're created only by the administrator, yes.

--- Additional comment from kay on 2012-03-27 12:09:09 EDT ---

A general note. We recommend:
  fsck.mode=force
  fsck.mode=skip
on the kernel commandline to control the behaviour, instead of these flags
required to be created on the live filesystem.

Needing to write to the filesystem which is requested to be checked, is a
pretty bad idea and a kind of backwards logic, hence we recommend using only
the kernel commandline options and not the historic way doing that.

Some day in the future, we might remove all support for the (broken) flag
files, because it is really the wrong way to control that kind of behaviour.

--- Additional comment from dwalsh on 2012-03-27 14:54:27 EDT ---

Fixed in selinux-policy-3.10.0-107.fc17

--- Additional comment from danielbelton on 2012-03-29 09:20:16 EDT ---

Daniel, it was also an issue in F16 as well. Is the selinux policy going to be updated for it as well?

--- Additional comment from mgrepl on 2012-03-29 09:22:26 EDT ---

Yes.

--- Additional comment from danielbelton on 2012-03-30 01:27:35 EDT ---

Installed the selinux-policy-3.10.0-108.fc17 from koji and it appears this issue has been resolved. 

The file /forcefsck is now removed once the filesystem checks are completed.

I will be using the fsck.mode=force on the kernel line in the future, though. I do agree, it is a bad idea to write to the filesystem that needs checking, and about the only time I use /forcefsck is when the root filesystem needs checking since that is is about the only one I can't umount and check while the system is up and running. 

Actually, it would be nice if the forced filesystem check could be limited to the root filesystem, but that is beyond the scope of this bug :)

--- Additional comment from updates on 2012-04-03 03:43:42 EDT ---

selinux-policy-3.10.0-110.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-110.fc17

--- Additional comment from updates on 2012-04-04 17:10:27 EDT ---

selinux-policy-3.10.0-110.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

--- Additional comment from igor.redhat on 2012-06-09 17:23:23 EDT ---

FWIW, this still hasn't been fixed for F16 as far as I can tell...

--- Additional comment from mgrepl on 2012-06-11 08:35:17 EDT ---

Please open a new bug for F16. Thank you.