From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Thu, 4 Oct 2012 08:08:11 -0400 Subject: [refpolicy] [PATCH] Changes to the dbus policy and its dependencies In-Reply-To: <1349304574.22995.32.camel@d30.localdomain> References: <1349302198.22995.25.camel@d30.localdomain> <1349304574.22995.32.camel@d30.localdomain> Message-ID: <506D7C2B.408@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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