Re: Use of optional_policy in templates (compiler bug or feature?)

[Joshua Brindle <method@manicmethod.com>]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.