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

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

[Sven Vermeulen]

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)?

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

[Dominick Grift]

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;

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

[Dominick Grift]

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.

Some might also argue that the role prefixed dbus_session_bus_client is
not needed/ not wanted but i beg to differ and wanted to at least
support it (it is already put to good use for wm as well as gkeyringd).

I am sorry for the inconvenience caused by this

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

[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

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

[Dominick Grift]

On Thu, 2012-10-04 at 08:08 -0400, Christopher J. PeBenito wrote:

> > 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.
> 

ok i will do so and use dbus_spec_session_bus_client()