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. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
