Hide Forgot
[This report has spawned from bug #658586.] kernel-2.6.32-112.el6.x86_64 util-linux-ng-2.17.2-9.el6.x86_64 gfs2-utils-3.0.12-33.el6.x86_64 When turning on/off quotas on mounted GFS2 by remount, I get following error message: # mount -o remount,quota=on /mnt/quota/ error mounting /dev/loop0 on /mnt/quota: Invalid argument # dmesg GFS2: invalid mount option: seclabel It depends on SELinux status. If enabled (enforcing or permissive mode), the bug will appear. If disabled, no error will appear. Other investigation shows: # strace -eexecve -s256 -fq mount -o remount,quota=on /mnt/quota/ execve("/bin/mount", ["mount", "-o", "remount,quota=on", "/mnt/quota/"], [/* 33 vars */]) = 0 [pid 1605] execve("/sbin/mount.gfs2", ["/sbin/mount.gfs2", "/dev/loop0", "/mnt/quota", "-o", "rw,remount,relatime,seclabel,localflocks,localcaching,quota=on,quota=on"], [/* 29 vars */]) = 0 error mounting /dev/loop0 on /mnt/quota: Invalid argument The mount helper is being added some options by /bin/mount. The options, including seclabel, come from /proc/mounts obviously: /dev/loop0 /mnt/quota gfs2 rw,seclabel,relatime,localflocks,localcaching,quota=on 0 0 I guess kernel adds the seclabel option on first mount, /bin/mount reuse it on remount.
We don't currently support selinux on GFS2, but we should resolve this bug anyway as we will support it at some future date.
I created a very simple gfs2 patch to get around this problem, but then I did some more in-depth analysis. It turns out that none of the other file systems have special processing for a "seclabel" mount parameter, and, in fact, it does not appear in the mount command within util-linux-ng either. I spoke with Eric Paris regarding this issue. It turns out the scope of this problem goes well beyond gfs2. Take, for example, bug #563267 which is a very similar issue. According to Eric: "So, 'seclabel' is an indicator added by the selinux code, that the filesystem is using xattrs for labels and that it supports label changes by setting the xattrs." ... "it's supposed to be stripped and ignored by the selinux mounts code..." "So I really think the right fix is to rearchitect the 'remount' code to pass things through the LSM to strip/handle non-fs specfic things (like we do on the normal mount code path)". "If you look at fs/super.c::vfs_kern_mount() you'll see where on normal mount we take the argument string, pass it to the LSM, and some things get stripped off. I don't think that happens in the remount code..." So it sounds like the right way to fix this is in the vfs layer.
Created attachment 478684 [details] GFS2 patch to get around the problem Here is the small gfs2 patch I whipped up to get around the problem. It was tested and works properly on test system gfs-i24c-01. However, as I previously noted, this is likely the wrong place to fix the issue.
Yes, that would be a much better plan, if possible.
We do not support selinux on GFS2? What part exactly is not supported?
Labelling on the filesystem. This is not tested at the moment, to the best of my knowledge and it won't work correctly in a cluster. See bz #437984
Eric, RE: comment #3, are you in a position to deal with the required VFS changes? If so I'll reassign to you, otherwise we can do the "quick fix" in mount.gfs2, but we need to know which to do at this stage.
Yes, you should reassign to me. I've already got a fix queued up for 2.6.39. I can backport for RHEL
Reassigning as requested in comment #9.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ff36fe2c845cab2102e4826c1ffa0a6ebf487c65 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=026eb167ae77244458fa4b4b9fc171209c079ba7
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Eric, is this ready to be posted for 6.2 now, or is there anything else that needs doing?
Eric, what is the current status of this patch?
I'm closing this bug as a dup of 656952. I accidentally posted these patches under that bug number and they were committed under that bug number. They should be available already in the -180 kernel.
*** This bug has been marked as a duplicate of bug 656952 ***