All of lore.kernel.org
 help / color / mirror / Atom feed
From: guido@trentalancia.com (Guido Trentalancia)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] [PATCH v4]: mcelog module initial rewrite
Date: Tue, 07 Aug 2012 22:20:40 +0200	[thread overview]
Message-ID: <50217898.1000106@trentalancia.com> (raw)
In-Reply-To: <1344368916.2306.14.camel@d30.localdomain>

On 07/08/2012 21:48, Dominick Grift wrote:
>
>
> On Tue, 2012-08-07 at 21:35 +0200, Guido Trentalancia wrote:
>> Hello Dominick.
>>
>> On 07/08/2012 19:43, Dominick Grift wrote:
>>>
>>>>
>>>> It's needed for the (untested) client mode.
>>>>
>>>> There is a boolean for that (and for the server mode, as one might want
>>>> to write another client for example).
>>>>
>>>
>>> Its already allowed... I will explain it one more time:
>>>
>>> allow mcelog_t self:unix_stream_socket create_stream_socket_perms;
>>> manage_sock_files_pattern(mcelog_t, mcelog_var_run_t, mcelog_var_run_t)
>>>
>>> is what allows this already. Its already there and therefore the
>>> stream_connect_pattern() is reduntant.
>>
>> I have triple-checked now, so at least you could double-check...
>>
>
> whoops you are right but in that case just do something like this
> instead:
>
> allow mcslog_t self:unix_stream_socket { create_socket_perms
> connectto; }

Yes, I think it can be done, but I would need to check. But is this not 
going to be considered overengineering ?

I don't like such term very much in this context anyway, as usually 
there is always an advantage in terms of maintanability.

> or show me the avc denials related to mcelog_t operating on mcelog_t
> unix stream sockets so that we can figure out the exact permissions.
>
> but using stream_connect_pattern() is not the way to go here

Initially you had suggested that pattern, so I went for that.

>> stream_connect_pattern() is needed for "connectto" (client-mode)
>>
>> removal of manage_sock_files_pattern would prevent sock_file creation:
>> it's the physical entry in the filesystem, not the logical socket
>> created by create_stream_socket_perms !
>
> I am not saying that you should remove it. I am saying that you should
> use the stream_connect_pattern()

>>> However i won't review it anymore because i have made my points already
>>> in previous reviews. No need for repeating myself.
>>
>> As already explained, all your revision have been introduced as applicable.
>>
>> My advice is to apply it as it is now and then you can submit further
>> patches as needed, which also seems much more efficient.
>
> It's not my call. I am just reviewing.
>
>> But I would strongly recommend you to also carry out some testing,
>> because otherwise, no matter how skilled you are, things similar to the
>> above might happen.
>
> It should be tested indeed
>
>> Regards,
>>
>> Guido

  reply	other threads:[~2012-08-07 20:20 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-06 15:19 [refpolicy] [PATCH v2]: mcelog module initial rewrite Guido Trentalancia
2012-08-06 15:30 ` Dominick Grift
2012-08-06 18:43   ` [refpolicy] [PATCH v3]: " Guido Trentalancia
2012-08-06 19:44     ` Dominick Grift
2012-08-07 17:34       ` [refpolicy] [PATCH v4]: " Guido Trentalancia
2012-08-07 17:43         ` Dominick Grift
2012-08-07 17:57           ` Guido Trentalancia
2012-08-07 19:35           ` Guido Trentalancia
2012-08-07 19:48             ` Dominick Grift
2012-08-07 20:20               ` Guido Trentalancia [this message]
2012-08-07 20:27                 ` Dominick Grift
2012-08-07 22:04                   ` [refpolicy] [PATCH v6]: " Guido Trentalancia
2012-08-08 13:02                     ` Christopher J. PeBenito
2012-08-08 14:34                       ` Guido Trentalancia
2012-08-08 14:41                         ` Christopher J. PeBenito
2012-08-08 19:33                       ` Guido Trentalancia
2012-08-09 16:34                         ` Christopher J. PeBenito
2012-08-09 21:54                           ` Guido Trentalancia
2012-08-10 14:47                             ` Christopher J. PeBenito
2012-08-10 19:27                               ` Guido Trentalancia
2012-08-14 12:23                                 ` Christopher J. PeBenito

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=50217898.1000106@trentalancia.com \
    --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.