Bug 676630
Summary: | Cannot remount GFS2 file system because of unsupported seclabel mount option | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Petr Pisar <ppisar> | ||||
Component: | kernel | Assignee: | Eric Paris <eparis> | ||||
Status: | CLOSED DUPLICATE | QA Contact: | Cluster QE <mspqa-list> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 6.2 | CC: | adas, anprice, bmarzins, ccaulfie, cluster-maint, dwalsh, eparis, jkortus, jrieden, kzak, lhh, rpeterso, swhiteho, teigland | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2011-08-15 19:24:04 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: | |||||||
Attachments: |
|
Description
Petr Pisar
2011-02-10 14:31:10 UTC
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 *** |