Bug 515741
Summary: | 2.6.30 kernel stopped supporting xattrs on hugetlbfs | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Daniel Berrangé <berrange> | ||||
Component: | kernel | Assignee: | Virtualization Maintenance <virt-maint> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 13 | CC: | 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 14:19:47 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: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 498969, 513462 | ||||||
Attachments: |
|
Description
Daniel Berrangé
2009-08-05 14:58:15 UTC
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. Created attachment 357394 [details]
Patch to resolve case relative to 2.6.31-rc5
John, could you post the latest status on this here? thanks 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. Okay, sounds like we'll have a patch suitable for F-12 soon 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 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 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. |