[refpolicy] [PATCH] Changes to the dbus policy and its dependencies

[cpebenito@tresys.com (Christopher J. PeBenito)]

On 10/03/12 18:49, Dominick Grift wrote:
> 
> 
> On Thu, 2012-10-04 at 00:09 +0200, Dominick Grift wrote:
>>
>> On Wed, 2012-10-03 at 23:54 +0200, Sven Vermeulen wrote:
>>> Recently, the dbus policy has seen some changes. At least one of them
>>> makes an interface incompatible with its earlier declaration.
>>>
>>> dbus_session_bus_client() previously took its argument as being a
>>> domain ($1) and now takes the argument to create its own domain
>>> ($1_dbusd_t). As a result, modules that used to do something like
>>> "dbus_session_bus_client(chromium_t)" are now broken.
>>>
>>> I'm wondering, how are we supposed to work with these interfaces now?
>>> Do we need to declare the subtype ourselves (I don't think the idea is
>>> to use the dbus_role_template for non-user domains, but it seems that
>>> this is the only interface that creates the specific type)?
>>
>> You need the dbus_all_session_bus_client(domain) now
>>
>> the dbus_session_bus_client() is for prefixed domains like gkeyringd for
>> example
>>
>> its finer grained. instead of allowing the caller to sendrecv to all
>> sessions busses you can define to which session bus the caller can
>> sendrecv
>>
>> it takes two params $1, role_prefix and $2 domain
>>
>> allow $2 $1_dbusd_t:dbus send_msg;
>>
>> vs.
>>
>> allow $1 session_bus_type:dbus send_msg;
>>
> 
> I know i should probably have deprecated the dbus_session_bus_client()
> but by doing so i would make the interface name unavailable for its new
> use.
> 
> Then it would get really messy and so i decided to just overlook this
> incident and go with this solution. There is one other similar case in
> the dbus module but i doubt anyone will hit that.

No, these need to be deprecated appropriately.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com