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
|
