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:
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):
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
'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"
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
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.
What does 'cat /proc/mounts' say? In particular, is /proc mounted ro?
'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.
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.
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.
/proc is normally mounted like that (see ls -lZd of /proc on a running system)
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.
> 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.
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.
Dan: but doesn't that mean the context won't be copied over?
Yes. The file context will not be preserved.
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?
> 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.
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!".
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