Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 230950 - anaconda confused by selinux
Summary: anaconda confused by selinux
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-05 00:01 UTC by Michal Jaegermann
Modified: 2007-12-14 11:19 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-12-14 11:19:20 UTC

Attachments (Terms of Use)
strace results after 'cp -a *log report/' (deleted)
2007-03-12 20:45 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2007-03-05 00:01:46 UTC
Description of problem:

After a boot with images using kernel-2.6.20-1.2962.fc7 and
in a shell supplied by ancoda if you try, say, this:

mkdir /tmp/logs
cp /tmp/syslog /tmp/logs/

then the second operation results in the following error:

cp: cannot set setfscreatecon `system_u:object_r:ramfs_t:s0': Read-only file system

That file system is not read-only.  If you will do instead

cat /tmp/syslog > /tmp/logs/syslog

then this works fine.  Also booting with 'selinux=0' kills that error.

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

How reproducible:

Comment 1 Jeremy Katz 2007-03-05 20:48:04 UTC
Can you strace this?  And run cp --version?

I suspect this is something in coreutils and related to the fact that /tmp
doesn't have selinux xattrs available

Comment 2 Michal Jaegermann 2007-03-06 01:54:55 UTC
'cp --version' shows "cp (GNU coreutils) 6.7".

As for 'strace' I have a problem.  I did not realize that strace
is available on a boot image and did not did that then.  Now I
am unable to reproduce the issue.  If I will use 'ls -lZ' then
all files and directories in /tmp have 'system_u:object_r:ramfs_t:s0'
label which was previously impossible to create.  No idea...
I did try few times yesterday and in the meantime nothing changed
in my boot images.

I tried booting with and without mounting any disk file systems
and now 'cp' does work without turning selinux off.  "Wrong date"

Comment 3 Jeremy Katz 2007-03-07 16:14:22 UTC
Cosmic rays maybe? :-)  I just tried and wasn't able to reproduce this, so going
to close it out.  If you manage to get it to happen again, reopen or file
another bug.

Comment 4 Michal Jaegermann 2007-03-12 20:45:07 UTC
Created attachment 149862 [details]
strace results after 'cp -a *log report/'

No, no cosmic rays.  I was hit by that again using 20070312
images.  These are using 2.6.20-1.2982.fc7 kernel.  But this time
I got strace output.  Here is what is "read-only"

gettid()				= 812
open("/proc/self/task/812/attr/fscreate", O_RDWR) = -1 EROFS (Read-only file

The catch is that 'cp *log report/' does work, but 'cp -a *log report/'
fails courtesy of selinux.

Comment 5 Tim Waugh 2007-03-27 10:08:50 UTC
What does 'cat /proc/mounts' say?  In particular, is /proc mounted ro?

Comment 6 Michal Jaegermann 2007-03-27 19:05:06 UTC
'cat /proc/mounts' shows everything mounted read/write, and that includes
/proc, with an exception of /mnt/source mounted from a remote and
/mnt/runtime on squashfs.  As expected.

'ls -lZd /proc' paints a different picture:
dr-xr-xr-x  root root system_u:object_r:proc_t:s0    /proc

Looking at few chains like then one which is used by 'open()' in
comment #4 and for some random process, not with "self" of course,
one can see that all their elements are rx-only with an exception
of a terminating "fscreate" (rw-rw-rw-).

If I will boot with 'selinux=0' then /proc is still 'dr-xr-xr-x'
despite of beeing mounted allegedy rw, and similarly down the
tree; but most likely I do not care.  Nothing probably will try
to write there.

Comment 7 Michal Jaegermann 2007-03-27 19:24:48 UTC
What I wrote in the previous comment gave me an idea.  I booted
with selinux active and did pretty crude 'chmod -R u+w /proc'.
This spit on me, of course, tons of "Operation not permitted",
but 'cp -a something somewhere' now works.

Comment 8 Tim Waugh 2007-03-27 22:20:51 UTC
cp is just using the libselinux API here; I think something needs to be changed
in the environment (perhaps the way /proc is mounted?) for cp -a to work.

Comment 9 Jeremy Katz 2007-04-02 15:20:22 UTC
/proc is normally mounted like that (see ls -lZd of /proc on a running system)

Comment 10 Daniel Walsh 2007-04-02 18:07:51 UTC
Are  you in permissive mode when this happens?  I think you are probably seeing
an "association" error in your log file.  cp -a attempts to preserve the file
context when doing a copy.  If it can not it will fail.  A new version of cp is
being worked on where this will warn but not fail.

cp -P would probably do what you want.  Or you could fix the file context on
/tmp with restorecon.


Comment 11 Michal Jaegermann 2007-04-02 18:38:10 UTC
> Are  you in permissive mode when this happens?

I do not think so.  Whatever anaconda is using by default.

The problem really is that selinux attempts to write in /proc tree
and this fails.  See comment #7 how to get around that and to make
'cp -a' to work without any fuss even in a presence of selinux.

The real issue here is not 'cp -a' as for that there is a simple
answer "do not use -a flag while copying in that context, then".
OTOH if any other operation will attempt to modify its
".../attr/fscreate", for whatever reasons, it will fail in the same manner.

Comment 12 Daniel Walsh 2007-04-03 13:43:22 UTC
Yes cp -a will attempt to setfscreatecon before copying the file.  If this fails
the command should check if it is in permissive mode (anaconda runs in
permissive mode).  If permissive cp should continue.

Comment 13 Tim Waugh 2007-04-03 16:12:27 UTC
Dan: but doesn't that mean the context won't be copied over?

Comment 14 Daniel Walsh 2007-04-03 17:23:25 UTC
Yes.  The file context will not be preserved.

Comment 15 Ondrej Vasik 2007-12-03 16:40:52 UTC
There is new version of coreutils in rawhide which should fix troubles with
failed  setfscreatecon. Not preserved file context is not considered as terminal
unless it is explicitly forced by an option. Could you please try if the latest
rawhide coreutils solved your troubles?

Comment 16 Michal Jaegermann 2007-12-03 21:34:57 UTC
> Could you please try if the latest
> rawhide coreutils solved your troubles?

Hm, so many things changed in the meantime that I am not even
sure how to test it.  I guess that I can try to repeat the
original problem with current rawhide installation images.
So, likely with much less effort, many other could do the same.

Comment 17 Michal Jaegermann 2007-12-14 03:10:27 UTC
I tried to repeat operations from comment #4 using installation
images dated 2007-12-12 from rawhide.  This did not get me very
far as anaconda gets SIGABRT immediately after configuring a network
and promptly reboots.  OTOH doing the same with images for F8
works just fine (I forgot about revisiting the issue).

I guess that this could be closed then, right?

Should I open another one for anaconda?  I cannot tell here very
much above "It does not work, Jim!".

Comment 18 Ondrej Vasik 2007-12-14 11:19:20 UTC
Ok, closing that RAWHIDE, as I think it is fixed by considering failure of
selfscreatecon as nonterminal. Please reopen the bug if the error will occur
with current coreutils.

About the part with opening bug against anaconda - there is already 700+ open
bugs against anaconda, so it is likely that this will be duplicate of something.
But you could open one if you want, it seems reasonable - even if there are not
enough informations.

Note You need to log in before you can comment on or make changes to this bug.