On Thu, 2008-10-23 at 10:10 -0400, 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.
I suppose it might be within an optional though in the original case,
just not in the trivial example produced by Joe to trigger the compiler
error.
> 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.
...even if that means a rewrite of the require + optional handling
altogether.
--
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.
