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 $? > 0 > 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. -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
