All of lore.kernel.org
 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 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.