Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
[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.
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.
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.
Comment 13RHEL Program Management
2011-05-13 15:27:05 UTC
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.
Comment 14Steve Whitehouse
2011-06-13 16:08:24 UTC
Eric, is this ready to be posted for 6.2 now, or is there anything else that needs doing?
Comment 15Steve Whitehouse
2011-07-18 14:15:25 UTC
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.