* [refpolicy] [PATCH] Changes to the dbus policy and its dependencies
@ 2012-10-03 21:54 Sven Vermeulen
2012-10-03 22:09 ` Dominick Grift
0 siblings, 1 reply; 5+ messages in thread
From: Sven Vermeulen @ 2012-10-03 21:54 UTC (permalink / raw)
To: refpolicy
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)?
^ permalink raw reply [flat|nested] 5+ messages in thread
* [refpolicy] [PATCH] Changes to the dbus policy and its dependencies
2012-10-03 21:54 [refpolicy] [PATCH] Changes to the dbus policy and its dependencies Sven Vermeulen
@ 2012-10-03 22:09 ` Dominick Grift
2012-10-03 22:49 ` Dominick Grift
0 siblings, 1 reply; 5+ messages in thread
From: Dominick Grift @ 2012-10-03 22:09 UTC (permalink / raw)
To: refpolicy
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;
^ permalink raw reply [flat|nested] 5+ messages in thread
* [refpolicy] [PATCH] Changes to the dbus policy and its dependencies
2012-10-03 22:09 ` Dominick Grift
@ 2012-10-03 22:49 ` Dominick Grift
2012-10-04 12:08 ` Christopher J. PeBenito
0 siblings, 1 reply; 5+ messages in thread
From: Dominick Grift @ 2012-10-03 22:49 UTC (permalink / raw)
To: refpolicy
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [refpolicy] [PATCH] Changes to the dbus policy and its dependencies
2012-10-03 22:49 ` Dominick Grift
@ 2012-10-04 12:08 ` Christopher J. PeBenito
2012-10-04 12:14 ` Dominick Grift
0 siblings, 1 reply; 5+ messages in thread
From: Christopher J. PeBenito @ 2012-10-04 12:08 UTC (permalink / raw)
To: refpolicy
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [refpolicy] [PATCH] Changes to the dbus policy and its dependencies
2012-10-04 12:08 ` Christopher J. PeBenito
@ 2012-10-04 12:14 ` Dominick Grift
0 siblings, 0 replies; 5+ messages in thread
From: Dominick Grift @ 2012-10-04 12:14 UTC (permalink / raw)
To: refpolicy
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()
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-10-04 12:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-03 21:54 [refpolicy] [PATCH] Changes to the dbus policy and its dependencies Sven Vermeulen
2012-10-03 22:09 ` Dominick Grift
2012-10-03 22:49 ` Dominick Grift
2012-10-04 12:08 ` Christopher J. PeBenito
2012-10-04 12:14 ` Dominick Grift
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.