selinux-refpolicy.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell Coker <russell@coker.com.au>
To: Chris PeBenito <pebenito@ieee.org>,
	"selinux-refpolicy@vger.kernel.org" 
	<selinux-refpolicy@vger.kernel.org>
Subject: Re: read_file_perms vs mmap_read_file_perms
Date: Sun, 10 Feb 2019 11:04:15 +1100	[thread overview]
Message-ID: <B1D5725E-37F2-4CB8-9558-39313518F862@coker.com.au> (raw)
In-Reply-To: <402f8da9-de40-3a9d-f767-324bc6f0e60b@ieee.org>

Now that we have just had a release it's a good time for changes that have the potential to break things. So removing lock now would be ok I guess.

On 10 February 2019 1:07:22 am AEDT, Chris PeBenito <pebenito@ieee.org> wrote:
>On 2/9/19 5:25 AM, Russell Coker wrote:
>> define(`read_file_perms',`{ getattr open read lock ioctl }')
>> define(`mmap_read_file_perms',`{ getattr open map read ioctl }')
>> 
>> I think that the general expectation would be that
>mmap_read_file_perms is a
>> superset of read_file_perms.  Is there any reason why
>mmap_read_file_perms
>> doesn't include lock permission?  If not I think we should add it to
>avoid
>> surprises.
>
>You are correct, it should be a proper superset.  However, my
>preference 
>would be to go the other way and eliminate lock from read_file_perms, 
>which is what I'm trying to do with mmap_read_file_perms not being a 
>proper superset.

-- 
Sent from my Huawei Mate 9 with K-9 Mail.

      reply	other threads:[~2019-02-10  0:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-09 10:25 read_file_perms vs mmap_read_file_perms Russell Coker
2019-02-09 14:07 ` Chris PeBenito
2019-02-10  0:04   ` Russell Coker [this message]

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=B1D5725E-37F2-4CB8-9558-39313518F862@coker.com.au \
    --to=russell@coker.com.au \
    --cc=pebenito@ieee.org \
    --cc=selinux-refpolicy@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).