Running targeted/enforcing, latest rawhide.
I created a 'backup' of my root lvm2 partition, mounted the new partition as /mnt, and copied the files via 'cp -dpR / /mnt'.
The copied files were all incorrectly labeled. (same result with cp --preserve=all').
I tried 'chroot /mnt; restorcon -v -R /', but it had no effect (returned immediately), as did any other resorecon attempted in the chroot'ed shell.
'setfiles -v /etc/selinux/targeted/contexts/files/file_contexts /' did the right thing.
[Its almost as if restorecon is using the 'real' full pathname (with leading /mnt), and setfiles is using the 'chroot'ed' pathname (without the leading /mnt).]
First, should the 'preserve' on cp have failed to copy the contexts? Second, why the difference in behavior between setfiles and restorecon in this context?
Still curious, tom
On Sat, 2005-08-27 at 12:58 -0700, Tom London wrote:
Running targeted/enforcing, latest rawhide.
I created a 'backup' of my root lvm2 partition, mounted the new partition as /mnt, and copied the files via 'cp -dpR / /mnt'.
The copied files were all incorrectly labeled. (same result with cp --preserve=all').
I tried 'chroot /mnt; restorcon -v -R /', but it had no effect (returned immediately), as did any other resorecon attempted in the chroot'ed shell.
'setfiles -v /etc/selinux/targeted/contexts/files/file_contexts /' did the right thing.
[Its almost as if restorecon is using the 'real' full pathname (with leading /mnt), and setfiles is using the 'chroot'ed' pathname (without the leading /mnt).]
First, should the 'preserve' on cp have failed to copy the contexts? Second, why the difference in behavior between setfiles and restorecon in this context?
Good questions. I know that at one time, there was debate over whether cp should ever preserve security contexts without use of an explicit option to that effect, as it might otherwise break existing users (because a process that may be able to preserve all of the DAC attributes might not be able to preserve the MAC label). However, it does seem unfortunate that a --preserve=all doesn't give you the intuitive result. I'm not sure what the right answer is there.
With regard to restorecon, a long time ago, Dan added a test on entry to it to immediately exit if SELinux wasn't enabled so that it could be safely called from the rc scripts regardless of whether SELinux was enabled or disabled. Since you are running it in a chroot environment, is_selinux_enabled will always fail because it cannot check /proc/filesystems for selinuxfs, so restorecon thinks that SELinux is disabled and exits silently. Possibly that should be removed or at least display a warning.
setfiles runs regardless of whether SELinux is enabled or disabled.
On Sat, 2005-08-27 at 12:58 -0700, Tom London wrote:
'setfiles -v /etc/selinux/targeted/contexts/files/file_contexts /' did the right thing.
[Its almost as if restorecon is using the 'real' full pathname (with leading /mnt), and setfiles is using the 'chroot'ed' pathname (without the leading /mnt).]
BTW, I'm not sure what you mean by the above. setfiles does accept a -r option to specify an alternate root path, so you can apply it to a chroot setup without running it chroot'd itself. But without that option, I wouldn't have expected it to touch /mnt at all, especially as file_contexts marks it <<none>>.
On 8/29/05, Stephen Smalley sds@tycho.nsa.gov wrote:
On Sat, 2005-08-27 at 12:58 -0700, Tom London wrote:
'setfiles -v /etc/selinux/targeted/contexts/files/file_contexts /' did the right thing.
[Its almost as if restorecon is using the 'real' full pathname (with leading /mnt), and setfiles is using the 'chroot'ed' pathname (without the leading /mnt).]
BTW, I'm not sure what you mean by the above. setfiles does accept a -r option to specify an alternate root path, so you can apply it to a chroot setup without running it chroot'd itself. But without that option, I wouldn't have expected it to touch /mnt at all, especially as file_contexts marks it <<none>>.
First, thanks for the explanation.
My comment regarding 'real' vs. 'chroot-ed' pathnames was just my feeble poke at explaning what was going on. I had noticed the entry for /mnt in file_contexts, and concluded that 1+1=3. ;)
Regarding setfiles, thanks for the info regarding '-r' option. Its not in the man page nor in 'setfiles --help', so I did the 'chroot' balancing act. 'setfiles -r' produces 'usage: setfiles -r rootpath' though.
tom
selinux@lists.fedoraproject.org