Bug 515741

Summary: 2.6.30 kernel stopped supporting xattrs on hugetlbfs
Product: [Fedora] Fedora Reporter: Daniel Berrange <berrange>
Component: kernelAssignee: Virtualization Maintenance <virt-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: high    
Version: 13CC: dwalsh, eparis, itamar, jcooper, jforbes, john.cooper, kernel-maint, markmc, virt-maint
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-27 10:19:47 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 513462, 498969    
Attachments:
Description Flags
Patch to resolve case relative to 2.6.31-rc5 none

Description Daniel Berrange 2009-08-05 10:58:15 EDT
Description of problem:
libvirt needs to use hugetlbfs as the backing store for KVM guest RAM. With sVirt, every KVM guest runs under a dedicated security context. To prevent guests accessing each other's RAM, we need to label files on hugetlbfs matching each guest.

This was possible on 2.6.29 kernels

# mount -t hugetlbfs none /mnt/
# cd /mnt
# touch foo bar
# chcon system_u:object_r:svirt_image_t:s0:c500 bar
# ls -lZ
-rw-r--r--. root root system_u:object_r:svirt_image_t:s0:c500 bar
-rw-r--r--. root root system_u:object_r:hugetlbfs_t:s0 foo
# uname -r
2.6.29.6-213.fc11.i686.PAE

But no longer works on 2.6.30



# mount -t hugetlbfs none /mnt/
# cd /mnt
# touch foo bar
# chcon system_u:object_r:svirt_image_t:s0:c500 bar
chcon: failed to change context of `bar' to `system_u:object_r:svirt_image_t:s0:c500': Operation not supported
# ls -lZ
-rw-r--r--. root root system_u:object_r:hugetlbfs_t:s0 bar
-rw-r--r--. root root system_u:object_r:hugetlbfs_t:s0 foo
# uname -r
2.6.31-0.118.rc5.fc12.x86_64

There is an explanation for this here:

http://www.redhat.com/archives/libvir-list/2009-July/msg00915.html

[quote Sephen Smalley]

> There is a vfs fallback for setxattr of the security.* namespace to the
> security module, which would work for hugetlbfs if not for the fact that
> policy defines it as a genfscon-labeled filesystem.  We only started
> prohibiting setxattr on genfscon-labeled filesystems in 2.6.30; prior to
> that we only did that for mountpoint-labeled filesystems.  I can
> actually chcon a file in a hugetlbfs mount on 2.6.29.

> To convert hugetlbfs to fully support labeling we'd need
> hugetlbfs_mknod() to call security_inode_init_security() to set up new
> inode security labels, just like shmem_mknod() does for tmpfs.  And then
> we'd need to switch over the policy from genfscon to fs_use_trans.
[/quote]


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 john cooper 2009-08-14 01:05:12 EDT
The attached patch restores the ability to {set,get}xattr(2)
on hugetlbfs inodes in 2.6.31-rc5 which should resolve this
case.  A tad more infrastructure needed to be pulled in to
support this functionality -- patch is attached but has yet
to be laundered upstream.

Also required is a modification of:

    serefpolicy-3.5.*/policy/modules/kernel/filesystem.te

to change hugetlbfs from genfscon to fs_use_xattr (Daniel
Walsh has captured the details).  Without this modification
selinux in enforcing mode will still disallow set/get of
inode xattrs.
Comment 2 john cooper 2009-08-14 01:11:24 EDT
Created attachment 357394 [details]
Patch to resolve case relative to 2.6.31-rc5
Comment 3 Mark McLoughlin 2009-10-06 11:33:48 EDT
John, could you post the latest status on this here? thanks
Comment 4 john cooper 2009-10-08 02:08:01 EDT
Since creating the fix captured in the above patch
I discovered there was another effort in flight
which addressed hubetlbfs xattr support but was more
comprehensive in scope.  I was unsure whether this
fix hit F12 beta as of kernel-2.6.31-0.125.4.2.rc5.git2.fc12.x86_64
however testing showed the problem still exists here.
Unfortunately no upstream fix is available to backport
as the earlier effort apparently was abandoned.

In the process of moving/verifying the above patch
to 2.6.31-0.125.4.2.rc5.git2.fc12, tripping over a
few build issues.  I believe this fix to be low-risk,
localized to hugetlbfs, and is simply reenabling
previously existing functionality.  Also as it is
still throttled by the security policy as described
above in comment #1, there is a userland resident
method to revert the feature.

The only minor unresolved issue associated with this
fix is a bit more concrete justification of
additional code needed to circumvent a !ptr dereference
in generic xattr operations, a clarification request
coming as a review comment from Stephen (TBD pending
fc12 kernel patch):

Stephen Smalley wrote:
> On Mon, 2009-08-17 at 16:23 -0400, john cooper wrote:
>> Stephen Smalley wrote:
>>
>>> However:
>>> 1) You don't really need the listxattr/setxattr/getxattr handlers since
>>> the vfs_* functions will fall back automatically to calling the security
>>> hooks if the fs doesn't provide any.  So I think you only need the
>>> security_inode_init_security() call.
>> That's where I had started given the advertising preceding
>> fs/xattr.c:xattr_resolve_name(),  However the generic_*xattr()
>> operations kept tripping over a NULL inode->i_sb->s_xattr ptr
>> (perhaps a latent bug).  It appeared pulling in the additional
>> infrastructure was less risk in this context compared with
>> circumventing the NULL ptr deref in common code.
> 
> I'm confused by that, as we get selinux xattr support for free for
> devpts by virtue of the vfs fallbacks.  We used to get it for free for
> tmpfs as well but they ultimately moved that down inside of tmpfs when
> they added POSIX ACL support.
Comment 5 Mark McLoughlin 2009-10-09 06:42:50 EDT
Okay, sounds like we'll have a patch suitable for F-12 soon
Comment 6 Bug Zapper 2010-03-15 08:45:08 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Bug Zapper 2011-06-02 13:51:46 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Bug Zapper 2011-06-27 10:19:47 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.