Description of problem: For a file system currently mounted with a context option, any "mount -o remount" will fail with a "bad option" complaint. This happens even when "context" is not mentioned in the remount options. Version-Release number of selected component (if applicable): util-linux-ng-2.16.2-5.fc12.x86_64 How reproducible: Always Steps to Reproduce: 1. Create an ext2 file system. 2. Mount the file system on /mnt with "-o context=system_u:object_r:file_t:s0" 3. Attempt to remount read-only with "mount -o remount,ro /mnt" Actual results: mount: /mnt not mounted already, or bad option (The file system remains mounted read/write.) Expected results: The FS should become read-only, with no error message. Additional info: This is different from bug 179437 (CLOSED CANTFIX) which was about an attempt to change the context option. It doesn't matter which mount option is being changed by the remount. Including the context option (unchanged) in the remount options does not help (no surprise there).
Do you want to say that kernel does not to accept unchanged context= option and the context= option cannot be used for -oremount at all? Then kernel is broken. See man mount, how mount(8) works with mount options for more than *15 years*: --- The remount functionality follows the standard way how the mount command works with options from fstab. It means the mount command doesn’t read fstab (or mtab) only when a device and dir are fully specified. mount -o remount,rw /dev/foo /dir After this call all old mount options are replaced and arbitrary stuff from fstab is ignored, except the loop= option which is internally generated and maintained by the mount command. mount -o remount,rw /dir After this call mount reads fstab (or mtab) and merges these options with options from com- mand line ( -o ). ---
note that: mount -v -v -v .... provides more details about all used options. Please, try it.
/etc/fstab is not involved. This partition is not mentioned there. I am not specifying any context, new or unchanged, in the remount command. Here are the exact commands, now with "-v -v -v" added, and results: # mount -o context=system_u:object_r:file_t:s0 /dev/sdb1 /mnt/tmp # mount | grep /mnt/tmp /dev/sdb1 on /mnt/tmp type ext2 (rw,context="system_u:object_r:file_t:s0") # grep sdb1 /proc/mounts /dev/sdb1 /mnt/tmp ext2 rw,context=system_u:object_r:file_t:s0,relatime,errors=continue 0 0 # mount -v -v -v -o remount,ro /mnt/tmp mount: fstab path: "/etc/fstab" mount: mtab path: "/etc/mtab" mount: lock path: "/etc/mtab~" mount: temp path: "/etc/mtab.tmp" mount: UID: 0 mount: eUID: 0 mount: spec: "/dev/sdb1" mount: node: "/mnt/tmp" mount: types: "ext2" mount: opts: "rw,context="system_u:object_r:file_t:s0",remount,ro" mount: translated context= 'system_u:object_r:file_t:s0' to 'system_u:object_r:file_t:s0' mount: mount(2) syscall: source: "/dev/sdb1", target: "/mnt/tmp", filesystemtype: "ext2", mountflags: -1058209759, data: context="system_u:object_r:file_t:s0" mount: /mnt/tmp not mounted already, or bad option #
It appears that the kernel simply does not accept any "context" option in the syscall for a remount. On a hunch, I edited /etc/mtab (Oh, the horror!) and removed the context option. The "mount -o remount,ro /mnt/tmp" then succeeded, with a warning about the lack of SELinux labels, with the resulting mount being read-only with _no_ context override. # mount -v -v -v -o remount,ro /mnt/tmp mount: fstab path: "/etc/fstab" mount: mtab path: "/etc/mtab" mount: lock path: "/etc/mtab~" mount: temp path: "/etc/mtab.tmp" mount: UID: 0 mount: eUID: 0 mount: spec: "/dev/sdb1" mount: node: "/mnt/tmp" mount: types: "ext2" mount: opts: "rw,remount,ro" mount: mount(2) syscall: source: "/dev/sdb1", target: "/mnt/tmp", filesystemtype: "ext2", mountflags: -1058209759, data: (null) /dev/sdb1 on /mnt/tmp type ext2 (ro) mount: /mnt/tmp does not contain SELinux labels. You just mounted an file system that supports labels which does not contain labels, onto an SELinux box. It is likely that confined applications will generate AVC messages and not be allowed access to this file system. For more details see restorecon(8) and mount(8). # mount | grep sdb1 /dev/sdb1 on /mnt/tmp type ext2 (ro) # This looks like a kernel bug. Removing a current overriding context and substituting the default one results in the same revocation quandary that made bug #179437 a CANTFIX.
(In reply to comment #3) > /etc/fstab is not involved. The /etc/mtab is involved. > # mount -v -v -v -o remount,ro /mnt/tmp unparsed option: > mount: opts: "rw,context="system_u:object_r:file_t:s0",remount,ro" final syscal: > mount: mount(2) syscall: source: "/dev/sdb1", target: "/mnt/tmp", > filesystemtype: "ext2", mountflags: -1058209759, data: > context="system_u:object_r:file_t:s0" Yes, it seems like a kernel bug. I think kernel should be able to accept (at least) unchanged context= option or ignore context= option for MS_REMOUNT at all. The current behaviour does not make any sense.
It appears that the kernel code always preserves any current context option (good!) but rejects any remount request that includes the context option even if unchanged from the current context. I find that by editing /etc/mtab and removing the context option, the remount succeeds and the Gospel According to /proc/mounts reveals that the previous context is in fact preserved (contrary to what I reported in comment #4, which was based on what 'mount' with no arguments reports). Right now (kernel-2.6.32.11-99.fc12.x86_64) I need to work around this incompatibility between the kernel and the mount command, and a simple script that removes the context option from /etc/mtab seems to do the job.
The kernel does not accept *context= options in a remount call (as you've noticed.) And this is semi-intentional. No remount call that changed the *context= would be valid. Those options are not even passed to the security system in the kernel. It 'could' be changed in the kernel such that the security system would check for *context= options and reject any call in which they were different from the original mount, but I don't think it gains a lot. You still could not ever 'use' *context= in a remount call. I personally think we are fine just closing this bug after seeing the changes you made to mount.tmpfs.
(In reply to comment #9) > It 'could' be changed in the kernel such that the > security system would check for *context= options and reject any call in which > they were different from the original mount, but I don't think it gains a lot. > You still could not ever 'use' *context= in a remount call. The problem is that mount(8) automatically add *context= option(s) from /etc/mtab to the all remount operations (if there was context= in the original (previous) mount(8) call). The mount options for the remount are always generated from mtab + command line. It means: mount /dev/sda1 /mnt -o context=foo mount -o remount,ro /mnt does not work, because the final remount options are remount,ro,context=foo We can add an exception for *context= options, but I think better solution is to improve kernel ;-) > I personally think we are fine just closing this bug after seeing the changes > you made to mount.tmpfs. Yes, the problem with tmpfs is fixed, but the problem will be still visible for people (who have *context= in fstab) with another filesystems.
Problem remains unchanged in Fedora 14, util-linux-ng-2.18-4.4.fc14.i686. A file system mounted with a "context=" option cannot be remounted unless /etc/mtab is first edited to remove all mention of the context option.
(In reply to comment #11) > Problem remains unchanged in Fedora 14, util-linux-ng-2.18-4.4.fc14.i686. A > file system mounted with a "context=" option cannot be remounted unless > /etc/mtab is first edited to remove all mention of the context option. My first thought was to not store the context option in mtab, but that's clearly the wrong way to do it. The proper way, which seems rejected, would be to strip the context option from the mtab information in the remount option handling, possibly starting with a flat reject of any mix of remount and context options in the users command line, since the context is predefined. Then the context from mtab could be removed and remount might actually work.
It definitely works if the context from /etc/mtab is stripped out. What I do for remount is run a script that edits /etc/mtab to strip out the context option from the entry I'm remounting, run the 'mount' command to do the remount, and then put the context data back in /etc/mtab. Pretty ugly and dangerous way to do business, but it works and I need it for an external drive that gets shared among systems with incompatible SELinux policies or no SELinux at all. Bad things happen if I allow security context to be attached to files there, so I have to use an overriding security context on the SELinux-enabled systems. The kernel already does a fine job of rejecting any remount with a context option.
util-linux-ng-2.18-4.5.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/util-linux-ng-2.18-4.5.fc14
util-linux-ng-2.18-4.5.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update util-linux-ng'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/util-linux-ng-2.18-4.5.fc14
This update (util-linux-ng-2.18-4.5.fc14) fixes the problem for me.
util-linux-ng-2.18-4.5.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.