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.
Bug 676630 - Cannot remount GFS2 file system because of unsupported seclabel mount option
Summary: Cannot remount GFS2 file system because of unsupported seclabel mount option
Keywords:
Status: CLOSED DUPLICATE of bug 656952
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Eric Paris
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-10 14:31 UTC by Petr Pisar
Modified: 2011-08-15 19:35 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-15 19:24:04 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
GFS2 patch to get around the problem (1.67 KB, patch)
2011-02-14 18:31 UTC, Robert Peterson 		no flags Details | Diff
View All

Description Petr Pisar 2011-02-10 14:31:10 UTC 
[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.
Comment 2 Steve Whitehouse 2011-02-10 14:38:26 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.
Comment 3 Robert Peterson 2011-02-14 18:30:01 UTC 
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.
Comment 4 Robert Peterson 2011-02-14 18:31:51 UTC 
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.
Comment 5 Steve Whitehouse 2011-02-14 18:49:52 UTC 
Yes, that would be a much better plan, if possible.
Comment 6 Jaroslav Kortus 2011-02-15 10:59:52 UTC 
We do not support selinux on GFS2? What part exactly is not supported?
Comment 7 Steve Whitehouse 2011-02-15 11:58:09 UTC 
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
Comment 8 Steve Whitehouse 2011-03-07 09:48:49 UTC 
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 9 Eric Paris 2011-03-07 17:03:09 UTC 
Yes, you should reassign to me.  I've already got a fix queued up for 2.6.39.  I can backport for RHEL
Comment 10 Robert Peterson 2011-03-18 18:14:05 UTC 
Reassigning as requested in comment #9.
Comment 12 Eric Paris 2011-04-01 20:47:18 UTC 
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
Comment 13 RHEL 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 14 Steve 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 15 Steve Whitehouse 2011-07-18 14:15:25 UTC 
Eric, what is the current status of this patch?
Comment 16 Eric Paris 2011-08-15 19:24:04 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.
Comment 17 Nate Straz 2011-08-15 19:35:06 UTC 

*** This bug has been marked as a duplicate of bug 656952 ***
Note You need to log in before you can comment on or make changes to this bug.