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): anaconda-11.2.0.28-1 How reproducible: always
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" yesterday?
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.
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 system) 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 enough informations.