Bug 806369
| Summary: | the /forcefsck file not being removed after filesystem check complete | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Daniel Belton <danielbelton> | |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 17 | CC: | dominick.grift, dwalsh, igor.redhat, johannbg, metherid, mgrepl, mschmidt, notting, plautrba, redhat, systemd-maint | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | selinux-policy-3.10.0-110.fc17 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 836644 (view as bug list) | Environment: | ||
| Last Closed: | 2012-04-04 21:10:27 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
|
Description
Daniel Belton
2012-03-23 15:03:43 UTC
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? 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 - 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 (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 [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> The AVC message could be in dmesg: dmesg|grep -i avc 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
Reassigning to selinux-policy. Please allow systemd-tmpfiles to delete files in the root directory. Thanks Michal for your very prompt response to this and all of your help in tracing the bug down :) So systemd-tmpfiles removes /forcefsck /forcequotacheck /fastboot which means it would allow systemd_tmpfiles_t to remove files in the root directory. Are these files created only by a user? They're created only by the administrator, yes. 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. Fixed in selinux-policy-3.10.0-107.fc17 Daniel, it was also an issue in F16 as well. Is the selinux policy going to be updated for it as well? Yes. 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 :) 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 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. FWIW, this still hasn't been fixed for F16 as far as I can tell... Please open a new bug for F16. Thank you. Apologies for the delay, here it is: bug 836644 (In reply to comment #13) > 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. This will be usefull if and only if there is a way to pass arguments into a rebooting kernel, like Solaris do: http://docs.oracle.com/cd/E19082-01/819-2240/reboot-1m/index.html While this is not possible, I really miss shutdown -F |