On Tue, 2009-01-13 at 22:08 -0700, Jerry James wrote:
> Josh Boyer was kind enough to give me a login on a ppc64 machine so I
> can try to debug the issue I'm having with GCL. Unfortunately, I
> cannot even get off the ground. I'm using a 'mock -r
> fedora-rawhide-ppc64' command to try things out. Inside the chroot, I
> see this:
> $ mock -r fedora-rawhide-ppc64 --shell
> INFO: mock.py version 0.9.13 starting...
> State Changed: init plugins
> State Changed: start
> State Changed: lock buildroot
> mock-chroot> selinuxenabled
> mock-chroot> echo $?
> mock-chroot> /usr/sbin/semodule -i /tmp/gcl.pp
> /usr/sbin/semodule: SELinux policy is not managed or store cannot be accessed.
> How is that supposed to work? This is blocking the GCL build, which
> has to change dumped images to type gcl_exec_t when SELinux is active
> (checked with selinuxenabled). If the policy is not managed or the
> store cannot be accessed, then selinuxenabled should be setting its
> exit code to 1, should it not? As it is, the GCL build fails when
> trying to invoke chcon because selinuxenabled is apparently lying.
selinuxenabled just tests for the presence of SELinux in the kernel by
probing for the selinuxfs filesystem (typically mounted on /selinux).
semodule is testing whether the policy store
(under /etc/selinux/$SELINUXTYPE/modules/active) exists and can be
accessed by the current process before proceeding to try to install your
module. strace semodule -i /tmp/gcl.pp would show the precise point of
failure, but offhand I'd guess that /etc/selinux/targeted/modules/active
either does not exist or is not readable by the process.
National Security Agency
fedora-devel-list mailing list