Bug 465276

Summary: Some block devices turn out to be read-only leading to read-only filesystems
Product: [Fedora] Fedora Reporter: QingLong <qinglong>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 9CC: dwalsh, notting, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-08 21:57:08 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 QingLong 2008-10-02 14:50:16 UTC
Description of problem:
During startup some block devices (on my last installation they were /dev/md5 and /dev/misc/var-lock (an LV located on /dev/md15)) turn out to be read-only
and are mounted read-only causing faults during the rest of startup curve.
But manually issueing `mount -a' (after this crippled startup finishes)
successfully remounts all those filesystems "read-write".
This bug does not occur (at least I haven't come across it) on installations
that use raw disc partitions for filesystems hosting (no software raid and lvm).
It looks like there is some race condition in udev (mdadm/lvm?)
or some other related subsystem.

Version-Release number of selected component (if applicable):
I've tried to upgrade the system(s) to latest available versions of RPMs,
but that has changed nothing.

How reproducible:
The phenomenon is hihly bound to a specific system:
if it has taken place during the first system boot,
it is 100% reproducible on that installation.

Steps to Reproduce:
I am not sure what is the minimal configuration that would display it,
but it looks like the more complex installation is
the more chances one gets to face this problem:
use numreous partitions, software raid devices, logical volumes, etc.

Actual results:


Expected results:


Additional info:

Comment 1 Bill Nottingham 2008-10-02 14:56:10 UTC
Without more information, it's going to be hard to attack this.

Do you have error messages that show when they were mounted read-only the first time?

Comment 2 QingLong 2008-10-04 18:29:15 UTC
 It looks like the problem is linked to selinux, there are messages in logs like
|
| type=1400 audit(1222921980.322:8): avc:  denied  { mounton } for  pid=1887 comm="mount" path="/var/spool" dev=md13 ino=125985 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir
|
 Nevertheless I think it also concerns initscripts as
subsequent manual `mount -a' does (re)mount the filesystems correctly.

Comment 3 Bill Nottingham 2008-10-07 14:33:56 UTC
CC'ing policy maintainer.

Have you done a full relabel?

Comment 4 QingLong 2008-10-07 15:06:38 UTC
Yes, I had done full relabel.

I've already contacted Fedora selinux mailing list,
by now I can conclude:
1. The problem reason is incorrectly labeled mount points,
   i.e. this is consequence of a bug in Fedora installation scripts.
   Relabel won't cure it, as by the moment of manually initiated
   full relabel all filesystems are already mounted,
   masking underlying mount points.
2. OTOH initscripts should be able to handle such situations
   similarly to (or within) full relabel perofrmed during startup
   on demand.
3. Temporary workaround is: setsebool -P allow_mount_anyfile 1
4. The problem is not so straightforward as some incorrectly labeled
   mount points are silently allowed to be used without even a warning.
   E.g. I had fixed all mount points labels but /var/lock,
   on the next boot ALL filesystems have been mounted successfully
   and no single message has been issued concerning /var/lock label.
5. It looks like this problem concerns restorecond as well.

Comment 5 Bill Nottingham 2008-10-07 15:19:22 UTC
initscripts can't reasonably parse any and all -EPERM on mount to attempt to guess what the label is, and what it should be to allow mount.

Comment 6 Daniel Walsh 2008-10-08 21:57:08 UTC
mount run by a user runs as unconfined, while mount run by initscripts is confined to be able to mount on files/directories defined in policy.  

You have two choices, you can either execute the boolean listed above or use
audit2allow to build custom policy to allow mount to mounton /var/lock

# grep mount /var/log/audit/audit.log | audit2allow -M mymount
# semodule -i mymount.pp