All of lore.kernel.org
 help / color / mirror / Atom feed
From: guido@trentalancia.com (Guido Trentalancia)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH/RFC 0/19]: patch set to update the git reference policy
Date: Mon, 24 Jan 2011 22:01:28 +0100	[thread overview]
Message-ID: <1295902888.31686.24.camel@tesla.lan> (raw)
In-Reply-To: <4D3DA1F3.7010705@gmail.com>

Hello Dominick,

thanks for your reply !

On Mon, 24/01/2011 at 16.59 +0100, Dominick Grift wrote:
> On 01/24/2011 04:56 PM, Guido Trentalancia wrote:
> >> I did a quick review of your policy and commented inline. I think most
> >> of it is probably not acceptable at this point unfortunately.
> > 
> > Yes, I have started to look at your comments. Of course they are all
> > good points that you have made and that need to be changed.
> > 
> > But after those issues will have been fixed, what else would prevent the
> > patch from being committed ?
> 
> For example the way you deal with dbus chat, is not the way refpolicy
> usually deas with it.

Yes, I know.

> Where you have dbus_*_send interfaces that only go one way, refpolicy
> uses dbus_*_chat interfaces that are bi-directional.
> 
> This is because if some process send a message and is allowed that, then
> one can be sure that the receiving party will want to reply to that
> message and that you will want to allow that reply (why else would you
> have allowed the initial party to send a message in the first place?

This is one thing I definitely not agree with. The way it's implemented
in the patch is better in my opinion. It is more flexible and it is more
in line with the aims of a reference policy.

One should not assume anything. Permissions to send_msg should be given
to each module separately only for what concerns that module (and not
the other party which might eventually be involved in a "chat"). A chat
is a concept too advanced for a reference policy. The policy should just
grant permissions for a module to send out something. It should not even
know that a "chat" is having place.

Of course, this is my point of view. If it necessarily needs to be the
other way to get committed, it can still be changed but I would
certainly do things differently on my side.

There are many changes that you propose. Apart from this latest one
(which is somewhat also mentioned in [2/19]), I am in perfect agreement
with what you say (well, to be honest I still need to look more
carefully at the feasibility of [5/19], [6/19], [8/19] and [13/19] but
there shouldn't be any problem as long as it is feasible).
Because there are many changes to carry out, I would prepare new patches
only if it is then worth committing them... Nobody else has commented
anything. I still think it's really worth applying these changes to the
reference policy (or otherwise it seems that basic functionality of a
generic system is not being guaranteed) !

I would really need to know before I proceed...

Regards,

Guido

  reply	other threads:[~2011-01-24 21:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-19  0:40 [refpolicy] RFC: patch to update git reference policy Guido Trentalancia
2011-01-20 13:18 ` Christopher J. PeBenito
2011-01-20 17:32   ` Guido Trentalancia
2011-01-21 12:37     ` Christopher J. PeBenito
2011-01-24  0:43       ` [refpolicy] [PATCH/RFC 0/19]: patch set to update the " Guido Trentalancia
2011-01-24 15:01         ` Dominick Grift
2011-01-24 15:56           ` Guido Trentalancia
2011-01-24 15:59             ` Dominick Grift
2011-01-24 21:01               ` Guido Trentalancia [this message]
2011-01-24 21:22                 ` Dominick Grift
     [not found]         ` <4D471319.2000907@tresys.com>
2011-01-31 21:18           ` Guido Trentalancia
2011-02-02 23:52             ` Martin Orr
2011-02-03  0:04               ` Guido Trentalancia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1295902888.31686.24.camel@tesla.lan \
    --to=guido@trentalancia.com \
    --cc=refpolicy@oss.tresys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.