Joshua Brindle wrote:
> Joe Nall wrote:
>>
>> On Oct 16, 2008, at 7:49 AM, Christopher J. PeBenito wrote:
>>
>>> On Wed, 2008-10-15 at 14:59 -0500, Joe Nall wrote:
>>>> On Oct 15, 2008, at 1:46 PM, Christopher J. PeBenito wrote:
>>>>
>>>>> On Wed, 2008-10-15 at 11:02 -0500, Joe Nall wrote:
>>>>>> Is it legitimate to define a type within an optional_policy within a
>>>>>> template?
>>>>>
>>>>> Yes.
>>>>>
>>>>>> I ask because there are a number of compile issues with policy that
>>>>>> look like:
>>>>>>
>>>>>> template(`wm_domain_template',`
>>>>>> ...
>>>>>> optional_policy(`
>>>>>> dbus_system_bus_client_template($1_wm,$1_wm_t)
>>>>>> # does not compile
>>>>>> # dbus_user_bus_client_template($1,$1_wm,$1_wm_t)
>>>>>> ')
>>>>>> ...
>>>>>> ')
>>>>>
>>>>> I can't reproduce this by just adding it to a random module; there are
>>>>> likely more factors that just the above template calls.
>>>>
>>>> Using stock Fedora targeted policy:
>>>>
>>>> policy_module(swo,1.0.0)
>>>>
>>>> userdom_unpriv_user_template(swo)
>>>> dbus_chat_user_bus(swo,swo_t)
>>>
>>> Well this is a weird case, because you have this situation:
>>>
>>> optional {
>>> # optionally declare the type
>>> # from userdom_unpriv_user_template(swo)
>>> type swo_dbusd_t;
>>> }
>>>
>>> # unconditionally require the type for this module
>>> # from dbus_chat_user_bus(swo,swo_t)
>>> require {
>>> type swo_dbusd_t;
>>> }
>>>
>>>
>>> but even if you make the second interface call optional too, you'll
>>> still get the compile error.
>>
>> Weird wrong or weird corner case that ought to work?
>>
>
> Weird unsupported. It was thought non-trivial to deterministically
> enable optionals in cases like this.
>
>
> --
> 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.
These cases happen to me all the time, and I end up having to code
around them in weird ways. As the policy gets more complicated and
interactions become more complex, we are going to see the compiler blow up.
dbus, xserver, confined users, are all causing interesting failure modes.
--
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.
