From: guido@trentalancia.com (Guido Trentalancia)
Date: Tue, 01 Feb 2011 21:03:30 +0100
Subject: [refpolicy] [PATCH/RFC 2/19]: patch set to update the git
 reference policy
In-Reply-To: <4D48132F.7070705@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>
Message-ID: <1296590610.3038.8.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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).

Therefore, I have always created new *_dbus_send() interfaces even where
*_dbus_chat() interfaces were present (and could in theory be used).

What do you think ?

Regards,

Guido