Bug 648653

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.

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" :)

~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.

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?

Any update on this issue?

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

Len you have a fc14 box running on tmpfs?

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.

Daniel,
On a fresh FC14 install, are you able to install xorg from rawhide?
If so, plese share with me the steps.

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.

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.

I thought the latest tmpfs did support extended attributes?

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/

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

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.

Whoops, but you figured it out.  I opened a new bug against policy to track this issue.

Dave, Eric does tmpfs support file capabilties in F15?

Could we carry those patches? This would seriously help me validate some 20 SRPMs I'm submitting to Fedora shortly :)

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.

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.

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.