linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Jeremy Allison'" <jra@samba.org>,
	"'J. Bruce Fields'" <bfields@fieldses.org>
Cc: "'Andreas Gruenbacher'" <agruenba@redhat.com>,
	"'Jan Kara'" <jack@suse.cz>, <linux-fsdevel@vger.kernel.org>,
	<lsf-pc@lists.linux-foundation.org>
Subject: RE: [Lsf-pc] [LSF/MM ATTEND] Richacls
Date: Tue, 13 Jan 2015 11:53:42 -0800	[thread overview]
Message-ID: <017d01d02f6a$a2e9e220$e8bda660$@mindspring.com> (raw)
In-Reply-To: <20150113180458.GF5830@samba2>

> On Tue, Jan 13, 2015 at 12:40:29PM -0500, J. Bruce Fields wrote:
> > On Tue, Jan 13, 2015 at 06:23:26PM +0100, Andreas Gruenbacher wrote:
> > > On 01/13/2015 05:48 PM, Jeremy Allison wrote:
> > > >My understanding of Christoph's objection (although I'm sure he can
> > > >chime in himself :-) was that he wanted to see POSIX ACLs reworked
> > > >as a mapping on top of RichACLs, so that ultimately RichACLs would
> > > >be the only on-disk format of the EA.
> > > >
> > > >I think that is doable, as I think any POSIX ACL can be represented
> > > >as an underlying RichACL, just not the reverse.
> > >
> > > On of the differences is that permissions in POSIX ACLs do
> > > accumulate, while in NFSv4 and CIFS ACLs, and therefore also
> > > richacls, they do not. So the two models are really not
> > > interchangeable, however annoying that may be.

I think Andreas got do and do not reversed (though looks like everyone read
it the right way...)

> > > For example, with the following POSIX ACL, a non-root process in
> > > group 5001 and 5002 would not be allowed to open f with O_RDWR, only
> > > with O_RDONLY *or* O_WRONLY.
> > >
> > >   # file: f
> > >   # owner: root
> > >   # group: root
> > >   user::rw-
> > >   group::rw-
> > >   group:5001:r--
> > >   group:5002:-w-
> > >   mask::rw-
> > >   other::---
> > >
> > > In all the other ACL models, the process would be allowed to open f
> > > with O_RDWR.

Hasn't this been resolved in in knfsd by use of DENY ACEs in converting the
POSIX ACL to NFS v4?

I just had a question though...

Can a process that is in both groups open two file descriptors, one
read-only and one write-only? I think so.

Assuming so, what happens with NFS v4 where the 2nd open results in an
open-upgrade over the wire to read-write?

> > If we modified the behavior to permit O_RDWR in this case, would that
> > cause anyone a problem?
> 
> Hmmmm. It changes userspace visible behavior. I can't think of any reason
> anyone would be relying on this (other than bugs :-) but still...

Yea, I would be wary of changing user space behavior. At the least, it MIGHT
cause someone's conformance test to fail. On the other hand, the POSIX ACL
draft never become a standard so no one would really have a complaint if
Linux's implementation were slightly different...

Frank


  reply	other threads:[~2015-01-13 20:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1626890778.1513173.1421087867777.JavaMail.zimbra@redhat.com>
2015-01-12 21:06 ` [LSF/MM ATTEND] Richacls Andreas Gruenbacher
2015-01-12 21:54   ` Jeremy Allison
2015-01-12 22:30   ` J. Bruce Fields
2015-01-13 10:14     ` [Lsf-pc] " Jan Kara
2015-01-13 15:07       ` Andreas Gruenbacher
2015-01-13 16:48         ` Jeremy Allison
2015-01-13 17:23           ` Andreas Gruenbacher
2015-01-13 17:29             ` Jeremy Allison
2015-01-13 17:40             ` J. Bruce Fields
2015-01-13 18:04               ` Jeremy Allison
2015-01-13 19:53                 ` Frank Filz [this message]
2015-01-13 20:24                   ` 'J. Bruce Fields'
2015-01-13 20:26                   ` Jeremy Allison
2015-01-13 20:30                     ` Jeremy Allison
2015-01-13 20:35                       ` Frank Filz
2015-01-14  7:57                   ` Andreas Gruenbacher
2015-01-13 21:04               ` Jan Kara
2015-01-13 21:16                 ` J. Bruce Fields
2015-01-13 21:20                   ` Jeremy Allison
2015-01-13 21:27                     ` Frank Filz
2015-01-13 21:31                   ` Jan Kara
2015-01-14  8:53                     ` Andreas Gruenbacher
2015-01-14 12:01                       ` Jeff Layton
2015-01-14 16:11                         ` J. Bruce Fields
2015-01-14 17:21                           ` Frank Filz
2015-01-23  5:31   ` Steve French

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='017d01d02f6a$a2e9e220$e8bda660$@mindspring.com' \
    --to=ffilzlnx@mindspring.com \
    --cc=agruenba@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=jack@suse.cz \
    --cc=jra@samba.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.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).