2011-02-01 20:59:49

by Guido Trentalancia

[permalink] [raw]
Subject: [refpolicy] [PATCH/RFC 2/19]: patch set to update the git reference policy

Hello Christopher !

On Tue, 01/02/2011 at 14.53 -0500, Christopher J. PeBenito wrote:
> On 02/01/11 15:03, Guido Trentalancia wrote:
> > Hello Christopher !
> >
> > On Tue, 01/02/2011 at 09.05 -0500, Christopher J. PeBenito wrote:
> >> On 01/31/11 18:15, Guido Trentalancia wrote:
> >>> Hello again Christopher !
> >>>
> >>> On Mon, 31/01/2011 at 13.52 -0500, Christopher J. PeBenito wrote:
> >>>> On 1/24/2011 9:24 AM, Dominick Grift wrote:
> >>>>> On 01/24/2011 01:43 AM, Guido Trentalancia wrote:
> >>>>
> >>>> Please include descriptions on each of your patches. The subject is
> >>>> definitely insufficient. I guess this is all the dbus changes you
> >>>> suggest? More
> >>>
> >>> The DBus send_msg issue is the probably the main change introduced by
> >>> the set of patches that I am proposing.
> >>>
> >>> The issue is very wide and needs careful approval. It's not limited to
> >>> this [2/19] patch/thread at all. It is mainly a style issue, but it's an
> >>> important one.
> >>>
> >>> In my reply to [0/19] I have pointed out a few threads where such issue
> >>> has been discussed more extensively between me and Dominick, because we
> >>> kept having different point of views and none of us managed to
> >>> definitely persuade the other !
> >>>
> >>> In any case, [2/19] and [8/19] are perhaps the most relevant places
> >>> where you can provide a definite direction on this (in short, can we
> >>> really talk about an hypothetical DBus "chat" throughout all refpolicy
> >>> and model interfaces accordingly to such assumption when on the other
> >>> hand the elementary data-flow in DBus is constituted by a
> >>> uni-directional message called "signal" ?).
> >>
> >> There already is an established verb for unidirectional dbus messaging:
> >> send. See unconfined_dbus_send() for an example. If there is
> >> unidirectional messaging, the policy should reflect that.
> >
> > Yes, unconfined_dbus_send() can be used in the context of the unconfined
> > domain.
> >
> > But then there are many other circumstances where DBus messaging needs
> > to take place. My original dbus-messaging patch ([2/19]) contains
> > several examples of where this appears to be needed.
> >
> > I prefer to grant two distinct and separate uni-directional send_msg
> > permissions in the two relevant modules anyway (even in the case of
> > bi-directional messaging).
>
> I'm not sure if I understand. Are you saying that you want to break
> apart the chat interfaces into individual send interfaces?
>
> eg:
>
> networkmanager_dbus_chat(hald_t)
>
> turns into
>
> networkmanager_dbus_send(hald_t)
> hald_dbus_send(networkmanager_t)
>
> (of course these would be in the proper modules)
>
> > Therefore, I have always created new *_dbus_send() interfaces even where
> > *_dbus_chat() interfaces were present (and could in theory be used).
>
> I don't have a problem with this.

Yes, I was referring exactly to that. Excellent.

Thanks a lot for your advice.

Best regards,

Guido