This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 465276 - Some block devices turn out to be read-only leading to read-only filesystems
Some block devices turn out to be read-only leading to read-only filesystems
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
9
All Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-02 10:50 EDT by QingLong
Modified: 2014-03-16 23:16 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-08 17:57:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description QingLong 2008-10-02 10:50:16 EDT
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 10:56:10 EDT
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 14:29:15 EDT
 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 10:33:56 EDT
CC'ing policy maintainer.

Have you done a full relabel?
Comment 4 QingLong 2008-10-07 11:06:38 EDT
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 11:19:22 EDT
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 17:57:08 EDT
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

Note You need to log in before you can comment on or make changes to this bug.