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   
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-
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
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?


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

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.