From: dominick.grift@gmail.com (Dominick Grift) Date: Thu, 04 Oct 2012 00:49:34 +0200 Subject: [refpolicy] [PATCH] Changes to the dbus policy and its dependencies In-Reply-To: <1349302198.22995.25.camel@d30.localdomain> References: <1349302198.22995.25.camel@d30.localdomain> Message-ID: <1349304574.22995.32.camel@d30.localdomain> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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