From: guido@trentalancia.com (Guido Trentalancia)
Date: Tue, 01 Feb 2011 21:59:49 +0100
Subject: [refpolicy] [PATCH/RFC 2/19]: patch set to update the git
 reference policy
In-Reply-To: <4D48649C.70000@tresys.com>
References: <1295829832.3862.61.camel@tesla.lan>
	<4D3D8BB5.4010501@gmail.com>  <4D4704F2.7080604@tresys.com>
	<1296515714.18286.79.camel@tesla.lan>  <4D48132F.7070705@tresys.com>
	<1296590610.3038.8.camel@tesla.lan>  <4D48649C.70000@tresys.com>
Message-ID: <1296593989.3038.13.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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