Bug 648653

Summary: tmpfs file systems do not support file capabilities.
Product: [Fedora] Fedora Reporter: Daniel Walsh <dwalsh>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: dougsland, eparis, gansalmon, gholms, itamar, jcm, jonathan, jwboyer, kernel-maint, len.brown, madhu.chinakonda, matt_domsch, mtoman, nsoranzo, paul, pva, rjones, scottt.tw, sgrubb, shawn.starr
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 689564 (view as bug list) Environment:
Last Closed: 2011-08-02 19:51:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 689564, 693731    

Description Daniel Walsh 2010-11-01 20:56:52 UTC
Description of problem:

In order to achieve the removesetuid feature for Fedora, tmpfs file systems have to support file cababilities, for mock builds.

On a tmpfs file system if I execute

setcap CAP_AUDIT_WRITE=ep seunshare 
 Failed to set capabilities on file `seunshare' (Operation not supported)

It blows up, it should work.

Comment 1 Eric Paris 2010-11-02 12:46:49 UTC
I started looking into this briefly.  Basically the problem is that tmpfs only supports xattrs that are provided by generic VFS type code.  aka only security.<lsm_flavor> and acls.  In the kernel these hang off the struct inode in inode->i_security and inode->i_acl respectively.  Like heck if we are going to get an inode->i_caps upstream, so we are going to need a better way.

I was thinking we might be able to attach a tree to the superblock with inode-to-cap mappings or something like that.  I'm not sure what the best solution is going to look like, but it's going to take a kernel change.  And most of the core kernel people I'd ask for advice are all at Kernel Summit for the next day or two.

Comment 2 Jon Masters 2010-11-16 07:46:39 UTC
Perhaps it might be possible to do something as a FUSE-fs. That would take time, so probably wouldn't be ready for this release. Personally, I don't see the value in removing setuid from files and prefer "it always was this way in UNIX" :)

Comment 3 Matt Domsch 2010-12-03 04:28:53 UTC
~3000 Fedora 15 (presently rawhide) packages fail to build in mock on F14 builders due to this, if mock uses tmpfs for its buildroot.  Out of 10k packages, that's a lot of failures. Back to the slow disk buildroot method I suppose...

FWIW, building F14 packages on the same F14 builders with tmpfs doesn't fail, and on 10 builders, I can rebuild the whole tree in under a day...  I'm expecting >30 hours when using the disk-backed buildroots.

Comment 4 Jon Masters 2010-12-03 21:46:19 UTC
What value are we getting from removing setuid anyway, other than changing something that was always done a certain way in UNIX for the sake of it?

Comment 5 Daniel Walsh 2011-01-05 18:11:18 UTC
Any update on this issue?

Comment 6 Len Brown 2011-01-29 02:50:08 UTC
What is the workaround?

Apparently I can't install rawhide fc15 Xorg onto fc14 because of this:


Error unpacking rpm package xorg-x11-server-Xorg-1.9.99.1-3.20101201.fc15.x86_64
error: unpacking of archive failed on file /usr/bin/Xorg: cpio: cap_set_file

Comment 7 Daniel Walsh 2011-02-01 22:46:56 UTC
Len you have a fc14 box running on tmpfs?

Comment 8 Len Brown 2011-02-02 01:30:57 UTC
It is a fresh install of FC14 on SSD w/ no modification.
The rpm install fails.  I assume the the RPM package software that unloads
the rpm is using tmpfs someplace.  I couldn't figure out how to get
around it, so for the time being I've abandoned fedora and rawhide.

Comment 9 Len Brown 2011-02-02 01:32:03 UTC
Daniel,
On a fresh FC14 install, are you able to install xorg from rawhide?
If so, plese share with me the steps.

Comment 10 Daniel Walsh 2011-02-02 13:35:15 UTC
I am just trying to figure out what is going on.  

tmpfs file systems do not support file capabilities until you get to a rawhide kernel, but I have no idea why RPM would be install Xorg packages into a tmpfs file system before putting it on to the F14 file system.  Now if you are doing a mock install on top of a tmpfs file system or rawhide, that might explain what is going on.

Comment 11 Michal Toman 2011-03-02 11:47:06 UTC
I am also experiencing this problem. Retrace Server uses mock to create fake chroots => yum is used to install required packages. The process is extremely slow on HDD, but using tmpfs results in a significant speed up. In order to process F15 crashes effectively, it would be really helpful to be able to use file capabilities in tmpfs.

Comment 12 Daniel Walsh 2011-03-02 19:23:30 UTC
I thought the latest tmpfs did support extended attributes?

Comment 13 Eric Paris 2011-03-02 19:27:08 UTC
Patches have been posted upstream but have fallen on deaf ears.  I'll ping upstream again, although maybe fedora wants to just carry them in the meantime?

https://lwn.net/Articles/422624/

Comment 14 Dave Jones 2011-03-19 00:16:55 UTC
I just realized that /var/lock is now on tmpfs in f16.  This is causing things like mrtg to fail..


type=AVC msg=audit(1300493461.829:2068): avc:  denied  { write } for  pid=5105 comm="mrtg" name="/" dev=tmpfs ino=7673 scontext=system_u:system_r:mrtg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lock_t:s0 tclass=dir

Comment 15 Eric Paris 2011-03-21 18:59:42 UTC
Comment #14 doesn't look related to tmpfs.  I also see what appear to be proper rules for this in selinux-policy-targeted-3.9.16-3.fc16.noarch.  What policy do you have?  If you are still having trouble what do you get from

sesearch --type --allow --source mrtg_t --target var_log_t --class dir

Comment 16 Dave Jones 2011-03-21 19:11:04 UTC
selinux-policy-targeted-3.9.16-5.fc16.noarch

Found 2 semantic av rules:
   allow domain var_log_t : dir { getattr search open } ; 
   allow mrtg_t var_log_t : dir { ioctl read write getattr lock add_name remove_name search open } ; 

Found 1 semantic te rules:
   type_transition mrtg_t var_log_t : dir mrtg_log_t; 


wait, did you mean var_lock_t maybe  ?

because that shows..

Found 1 semantic av rules:
   allow mrtg_t var_lock_t : dir { getattr search open } ; 

which doesn't have a 'write', which would explain the denial.

Comment 17 Eric Paris 2011-03-21 19:26:25 UTC
Whoops, but you figured it out.  I opened a new bug against policy to track this issue.

Comment 18 Daniel Walsh 2011-04-05 13:28:16 UTC
Dave, Eric does tmpfs support file capabilties in F15?

Comment 19 Shawn Starr 2011-07-20 23:59:55 UTC
Could we carry those patches? This would seriously help me validate some 20 SRPMs I'm submitting to Fedora shortly :)

Comment 20 Matt Domsch 2011-07-21 04:22:06 UTC
The F15 kernel doesn't have the patches, but the rawhide kernel does.  For my builders I grabbed a build from koji just before the 3.0.0 kernel naming convention hit - the last of the 2.6.x series.

Comment 21 Josh Boyer 2011-08-02 19:51:28 UTC
rawhide, f16, and f15 (2.6.40) should have a kernel that contains these changes.  This can be closed as far as I can tell.  Please re-open if I've missed something.

Comment 22 Paul Howarth 2011-08-02 20:37:47 UTC
I can confirm that mock is working for me building rawhide targets using tmpfs with the 2.6.40 kernel on an f15 host; this was not working with the original f15 kernel.