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.
--
Stephen Smalley
National Security Agency
--
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.
