On Wed, 2009-01-14 at 10:30 -0700, Jerry James wrote: > On Wed, Jan 14, 2009 at 7:02 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > 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. > > Thanks, Stephen and Jesse. This is helpful information. So here's > the problem I'm having. I have defined a policy that creates process > type gcl_t and file type gcl_exec_t. This policy allows GCL to do a > number of strange things to memory (execheap, for example). GCL > creates multiple dump files as it builds, each leading up to the final > dump file to be packaged. Each dump file has to be labeled gcl_exec_t > if the build is happening on an SELinux-enabled system. I patched the > GCL makefiles to include lines like this: > > if [ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled; then \ > chcon -t gcl_exec_t $@; \ > fi > > This works fine when I do a normal build on my home (SELinux-enabled) > machine. It also works on the koji builders, where SELinux is not > enabled. However, it is failing in mock on an SELinux-enabled > machine. How should I change the test so that chcon isn't run if it > is going to fail? Or should I just ignore chcon failures? Thanks, If the chcon fails, won't the subsequent attempt to execute the dump file also fail due to lack of permissions? Ideally you'd get your domain (or perhaps just a more generic unconfined_execheap_t domain) added to the base policy and included in the policy on the build servers so that you could use an already defined file type. Alternatively, you might be able to workaround via setting the existing allow_execheap boolean if that exists on those machines: setsebool allow_execheap = 1 <run your build> setsebool allow_execheap = 0 That unfortunately will affect more than just your particular process, but may be a temporary fix. -- Stephen Smalley National Security Agency -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
