Stephen Smalley wrote:
On Wed, 2008-10-22 at 13:42 -0400, Joshua Brindle wrote:
Stephen Smalley wrote:
On Wed, 2008-10-22 at 10:28 -0400, Stephen Smalley wrote:
On Wed, 2008-10-22 at 09:26 -0500, Joe Nall wrote:
On Oct 22, 2008, at 9:01 AM, Stephen Smalley wrote:
I did notice however that I could also get it to build w/o
changing checkmodule by reversing the order of the interface calls
there
- not sure if that workaround is usable in the original case that
triggered this bug report.
Arranging modules in the proper order becomes increasingly difficult
as module interaction grows. I finally de-optioned the X policy in
fedora since it is in base so get our additions to compile. Patch
included for reference.
Making the compiler gracefully deal with options would really be
appreciated. I could see the issue in the compiler code, but the right
fix wasn't obvious.
Does the patch I posted fix your problem?
And by fix, I mean not only does it allow you to build the policy but
does it yield the expected final kernel policy (i.e. look at the
policy.N file via apol and check that you are getting the expected types
and rules in the final policy).
I just worry that allowing situations like this will cause the linker to
not properly (or deterministically) enable optional blocks. That is why
we require everything be scoped locally to be used. We have, however,
made changes to the linker algorithm since the original module codebase
so it might have gotten better, but I don't think anyone has sat down
and figured out exactly which cases can be required and which ones may
be prevented.
The particular case is:
optional {
require {
type system_dbusd_t, system_dbusd_t, dbusd_etc_t;
class dbus { send_msg acquire_svc };
attribute dbusd_unconfined;
}
type swo_dbusd_t;
...
}
require {
type swo_t;
type swo_dbusd_t;
class dbus send_msg;
}
...
So the require that is triggering a misleading "duplicate
type/attribute" error under the current toolchain is not within an
optional block at all. And if you switch the order, it compiles fine
(because we already allow decl-follows-require). It shouldn't be order
dependent obviously.
In any event, the compiler breakage is preventing people from doing real
work, and doesn't seem to be a bug in policy. It needs to be fixed.
Ok, waiting on Joe to respond with whether your last patch fixed his
problems then I'll apply it here and see if it blows anything up.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
