Changes to the dbus policy and its dependencies

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

Quoted 8 lines · 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.

Quoted 4 lines

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;

Quoted 24 lines · Dominick Grift

Quoted 8 lines · 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.

Quoted 4 lines

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

Quoted 8 lines

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.

Quoted 7 lines

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.