[LSF/MM ATTEND] Richacls

[LSF/MM ATTEND] Richacls

[Andreas Gruenbacher]

Hello,

I would like to discuss the status and next steps for completing
richacl support (http://en.wikipedia.org/wiki/Richacls) in
the vfs, local file systems, nfs, cifs.

Right now, we don't have kernel support for a file permission
model powerful enough to support both POSIX permissions and
NFSv4 / CIFS access control lists at the same time.  As a result,
support for the NFSv4 and CIFS permission models is very limited,
and permission wise, Linux is neither a very good client nor
server to other systems.  For example, the permission to only
append to a file or to take ownership of a file cannot be
represented.  When files are copied across systems, file
permissions change or are lost.  This should be improved.

I've started working on this a long time ago but didn't have
enough time to complete it.  More recently, Aneesh Kumar has
spent time on this topic (http://lwn.net/Articles/596517/) but
eventually also stopped working on it.  Things have improved on
my side and I'll be able to work on this again now, though.

Thanks,
Andreas

Re: [LSF/MM ATTEND] Richacls

[Jeremy Allison]

On Mon, Jan 12, 2015 at 04:06:44PM -0500, Andreas Gruenbacher wrote:
> Hello,
> 
> I would like to discuss the status and next steps for completing
> richacl support (http://en.wikipedia.org/wiki/Richacls) in
> the vfs, local file systems, nfs, cifs.
> 
> Right now, we don't have kernel support for a file permission
> model powerful enough to support both POSIX permissions and
> NFSv4 / CIFS access control lists at the same time.  As a result,
> support for the NFSv4 and CIFS permission models is very limited,
> and permission wise, Linux is neither a very good client nor
> server to other systems.  For example, the permission to only
> append to a file or to take ownership of a file cannot be
> represented.  When files are copied across systems, file
> permissions change or are lost.  This should be improved.
> 
> I've started working on this a long time ago but didn't have
> enough time to complete it.  More recently, Aneesh Kumar has
> spent time on this topic (http://lwn.net/Articles/596517/) but
> eventually also stopped working on it.  Things have improved on
> my side and I'll be able to work on this again now, though.
> 
> Thanks,
> Andreas

Andreas, I would be very keen on seeing you complete
this work, and am willing to actively test any code
you may produce with Samba !

Thanks,

Jeremy.

Re: [LSF/MM ATTEND] Richacls

[J. Bruce Fields]

On Mon, Jan 12, 2015 at 04:06:44PM -0500, Andreas Gruenbacher wrote:
> I would like to discuss the status and next steps for completing
> richacl support (http://en.wikipedia.org/wiki/Richacls) in
> the vfs, local file systems, nfs, cifs.
> 
> Right now, we don't have kernel support for a file permission
> model powerful enough to support both POSIX permissions and
> NFSv4 / CIFS access control lists at the same time.  As a result,
> support for the NFSv4 and CIFS permission models is very limited,
> and permission wise, Linux is neither a very good client nor
> server to other systems.  For example, the permission to only
> append to a file or to take ownership of a file cannot be
> represented.  When files are copied across systems, file
> permissions change or are lost.  This should be improved.
> 
> I've started working on this a long time ago but didn't have
> enough time to complete it.  More recently, Aneesh Kumar has
> spent time on this topic (http://lwn.net/Articles/596517/) but
> eventually also stopped working on it.  Things have improved on
> my side and I'll be able to work on this again now, though.

This has been stalled a while and it will be good to see it unstuck.

Don't know if if it needs time on the official schedule but I'd look
forward to discussing it in the hallway....

--b.

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Jan Kara]

On Mon 12-01-15 17:30:16, J. Bruce Fields wrote:
> On Mon, Jan 12, 2015 at 04:06:44PM -0500, Andreas Gruenbacher wrote:
> > I would like to discuss the status and next steps for completing
> > richacl support (http://en.wikipedia.org/wiki/Richacls) in
> > the vfs, local file systems, nfs, cifs.
> > 
> > Right now, we don't have kernel support for a file permission
> > model powerful enough to support both POSIX permissions and
> > NFSv4 / CIFS access control lists at the same time.  As a result,
> > support for the NFSv4 and CIFS permission models is very limited,
> > and permission wise, Linux is neither a very good client nor
> > server to other systems.  For example, the permission to only
> > append to a file or to take ownership of a file cannot be
> > represented.  When files are copied across systems, file
> > permissions change or are lost.  This should be improved.
> > 
> > I've started working on this a long time ago but didn't have
> > enough time to complete it.  More recently, Aneesh Kumar has
> > spent time on this topic (http://lwn.net/Articles/596517/) but
> > eventually also stopped working on it.  Things have improved on
> > my side and I'll be able to work on this again now, though.
> 
> This has been stalled a while and it will be good to see it unstuck.
> 
> Don't know if if it needs time on the official schedule but I'd look
> forward to discussing it in the hallway....
  As far as I remember (and I'm sorry if I'm too explicit here) the main
issue is to find a way of implementing the features necessary for RichACLs
in a way acceptable for Al and Christoph Hellwig. I specifically remember
Christoph having strong opinions on the rich ACL features as such. I don't
remember the details but the first step is IMO that someone who understands
the needs of NFS and Samba talks to them about what would be an acceptable
extension of the permission model we have.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Andreas Gruenbacher]

On 01/13/2015 11:14 AM, Jan Kara wrote:
>As far as I remember (and I'm sorry if I'm too explicit here) the main
> issue is to find a way of implementing the features necessary for RichACLs
> in a way acceptable for Al and Christoph Hellwig. I specifically remember
> Christoph having strong opinions on the rich ACL features as such.

I'm aware of two major kinds of issues: first, if the permission model 
as implemented in the current (old) patch set makes sense and if a 
simplified model isn't enough, and second, if richacls really need to be 
represented differently than POSIX ACLs which are already in the kernel 
(struct posix_acl).

I think the features that the permission model that the richacl patches 
implement are needed and that a simplified model wouldn't be useful. As 
far as the implementation goes, there are significant differences among 
the two models (richacl entries can either allow or deny something, the 
order of entries matters, and instead of having "access" as well as 
default acls as separate objects, inheritance is determined by flags of 
the acl and its entries). But that doesn't require that different 
objects need to be used for representing the two kinds of acls: shoving 
both models into the same object type would make the details slightly 
more difficult to understand but those details would be somewhat hidden
at the "layer above" as well. I'll try if that approach holds any value.

Thanks,
Andreas

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Jeremy Allison]

On Tue, Jan 13, 2015 at 04:07:47PM +0100, Andreas Gruenbacher wrote:
> On 01/13/2015 11:14 AM, Jan Kara wrote:
> >As far as I remember (and I'm sorry if I'm too explicit here) the main
> >issue is to find a way of implementing the features necessary for RichACLs
> >in a way acceptable for Al and Christoph Hellwig. I specifically remember
> >Christoph having strong opinions on the rich ACL features as such.
> 
> I'm aware of two major kinds of issues: first, if the permission
> model as implemented in the current (old) patch set makes sense and
> if a simplified model isn't enough, and second, if richacls really
> need to be represented differently than POSIX ACLs which are already
> in the kernel (struct posix_acl).
> 
> I think the features that the permission model that the richacl
> patches implement are needed and that a simplified model wouldn't be
> useful. As far as the implementation goes, there are significant
> differences among the two models (richacl entries can either allow
> or deny something, the order of entries matters, and instead of
> having "access" as well as default acls as separate objects,
> inheritance is determined by flags of the acl and its entries). But
> that doesn't require that different objects need to be used for
> representing the two kinds of acls: shoving both models into the
> same object type would make the details slightly more difficult to
> understand but those details would be somewhat hidden
> at the "layer above" as well. I'll try if that approach holds any value.

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.

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Andreas Gruenbacher]

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.

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.

The rationale for this behavior in POSIX ACLs was / is consistency with 
how the traditional POSIX file permission model works -- determine which 
of the (three) sets of permissions applies to a process, then check only 
that set.

Thanks,
Andreas

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Jeremy Allison]

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.
> 
> 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.
> 
> The rationale for this behavior in POSIX ACLs was / is consistency
> with how the traditional POSIX file permission model works --
> determine which of the (three) sets of permissions applies to a
> process, then check only that set.

Really good point, and the one case I'd forgotten about :-).

Thanks for pointing it out !

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[J. Bruce Fields]

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.
> 
> 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.

If we modified the behavior to permit O_RDWR in this case, would that
cause anyone a problem?

> The rationale for this behavior in POSIX ACLs was / is consistency
> with how the traditional POSIX file permission model works --
> determine which of the (three) sets of permissions applies to a
> process, then check only that set.

The "consistency" leads to kind of weird corner case here.

--b.

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Jeremy Allison]

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.
> > 
> > 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.
> 
> 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...

RE: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Frank Filz]

> 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

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

['J. Bruce Fields']

On Tue, Jan 13, 2015 at 11:53:42AM -0800, Frank Filz wrote:
> > 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.

Yep.

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

If anyone cares: currently knfsd will attempt a single read-write open
if a client does a read-write open, but if a client (for example) opens
for read and then upgrades for write, nfsd will do a read-only open and
then a write-only open.  So given the above acl that open+upgrade
sequence would succeed where the read-write open would fail.

> > > 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...

I doubt anyone worries about that so much as about breaking something on
upgrade due to someone expecting the older behavior.

That sounds unlikely, though.

--b.

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Jeremy Allison]

On Tue, Jan 13, 2015 at 11:53:42AM -0800, Frank Filz wrote:
> > 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?

No, it can't work.

Consider a non-root process in group 5001 and 5002.

The obvious way to map the above POSIX ACL to NFSv4
is:

1) group:5001:DENY:WRITE
2) group:5001:ALLOW:READ
3) group:5002:DENY:READ
4) group:5001:ALLOW:WRITE

But NFSv4/CIFS permissions are cummulative. So
requesting O_WRONLY will always fail as it runs
into rule number 1.

So let's reorder it:

1) group:5002:DENY:READ
2) group:5001:ALLOW:WRITE
3) group:5001:DENY:WRITE
4) group:5001:ALLOW:READ

Now O_RDONLY fails due to rule #1 :-(.

If we put both DENY rules first, both
O_RDONLY and O_WRONLY fail. If we put both
ALLOW rules first, then O_RDWR is allowed,
which shouldn't be.

There's just no way to get to the "or" behavior
from here.

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Jeremy Allison]

On Tue, Jan 13, 2015 at 12:26:42PM -0800, Jeremy Allison wrote:
> On Tue, Jan 13, 2015 at 11:53:42AM -0800, Frank Filz wrote:
> > > 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?
> 
> No, it can't work.
> 
> Consider a non-root process in group 5001 and 5002.
> 
> The obvious way to map the above POSIX ACL to NFSv4
> is:
> 
> 1) group:5001:DENY:WRITE
> 2) group:5001:ALLOW:READ
> 3) group:5002:DENY:READ
> 4) group:5001:ALLOW:WRITE

Bah, got the group ID's wrong. Should be:

1) group:5001:DENY:WRITE
2) group:5001:ALLOW:READ
3) group:5002:DENY:READ
4) group:5002:ALLOW:WRITE

of course.

> But NFSv4/CIFS permissions are cummulative. So
> requesting O_WRONLY will always fail as it runs
> into rule number 1.
> 
> So let's reorder it:
> 
> 1) group:5002:DENY:READ
> 2) group:5001:ALLOW:WRITE
> 3) group:5001:DENY:WRITE
> 4) group:5001:ALLOW:READ

and:

1) group:5002:DENY:READ
2) group:5002:ALLOW:WRITE
3) group:5001:DENY:WRITE
4) group:5001:ALLOW:READ

RE: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Frank Filz]

> On Tue, Jan 13, 2015 at 12:26:42PM -0800, Jeremy Allison wrote:
> > On Tue, Jan 13, 2015 at 11:53:42AM -0800, Frank Filz wrote:
> > > > 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?
> >
> > No, it can't work.
> >
> > Consider a non-root process in group 5001 and 5002.
> >
> > The obvious way to map the above POSIX ACL to NFSv4
> > is:
> >
> > 1) group:5001:DENY:WRITE
> > 2) group:5001:ALLOW:READ
> > 3) group:5002:DENY:READ
> > 4) group:5001:ALLOW:WRITE
> 
> Bah, got the group ID's wrong. Should be:
> 
> 1) group:5001:DENY:WRITE
> 2) group:5001:ALLOW:READ
> 3) group:5002:DENY:READ
> 4) group:5002:ALLOW:WRITE
> 
> of course.
> 
> > But NFSv4/CIFS permissions are cummulative. So requesting O_WRONLY
> > will always fail as it runs into rule number 1.
> >
> > So let's reorder it:
> >
> > 1) group:5002:DENY:READ
> > 2) group:5001:ALLOW:WRITE
> > 3) group:5001:DENY:WRITE
> > 4) group:5001:ALLOW:READ
> 
> and:
> 
> 1) group:5002:DENY:READ
> 2) group:5002:ALLOW:WRITE
> 3) group:5001:DENY:WRITE
> 4) group:5001:ALLOW:READ

Oh , yea, I should have thought it all the way through...

Did we make allowance in RichACL to represent the POSIX behavior? There's
also the POSIX ACL mask. Of course if we did have a representation, we
couldn't preserve the ACL when using NFS v4 to copy from one location to
another.

Frank

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Jan Kara]

On Tue 13-01-15 12:40:29, 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.
> > 
> > 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.
> 
> If we modified the behavior to permit O_RDWR in this case, would that
> cause anyone a problem?
  As others noted, this changes user visible behavior and I don't think we
can do that. In the discussion about user namespaces, we for example
specifically disallowed unpriviledged process to drop some group membership
exactly because it can actually result in process suddently being able to
access some files and reportedly there are setups which are using group
membership to *restrict* access.
 
> > The rationale for this behavior in POSIX ACLs was / is consistency
> > with how the traditional POSIX file permission model works --
> > determine which of the (three) sets of permissions applies to a
> > process, then check only that set.
> 
> The "consistency" leads to kind of weird corner case here.
  I agree it's somewhat weird but it's how traditional unix permissions
have worked since day one so we better get used to that ;)

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[J. Bruce Fields]

On Tue, Jan 13, 2015 at 10:04:40PM +0100, Jan Kara wrote:
> On Tue 13-01-15 12:40:29, 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.
> > > 
> > > 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.
> > 
> > If we modified the behavior to permit O_RDWR in this case, would that
> > cause anyone a problem?
>   As others noted, this changes user visible behavior and I don't think we
> can do that. In the discussion about user namespaces, we for example
> specifically disallowed unpriviledged process to drop some group membership
> exactly because it can actually result in process suddently being able to
> access some files and reportedly there are setups which are using group
> membership to *restrict* access.

Right, but look at the case above carefully again--it's *much* more
special than the one the container people hit.

You can absolutely still represent weird modes like 026 with a Richacl
and it will deny permissions in the traditional way.

What you can't do is represent the above POSIX ACL.

This is a case that you can *only* hit with POSIX ACLs (not with mode
bits).  And that's because the POSIX ACL is doing something bizarre and
useless that I've never seen any other ACL system do (denying read and
write together when each would be permitted separately).

Using the usual "if a tree fell in a forest and nobody heard it..."
criterion, I think this change would be unlikely to cause us trouble.

Anyway, I don't think it's something to get hung up on, if we really had
to we could work out some sort of backwards compatibility here.

--b.

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Jeremy Allison]

On Tue, Jan 13, 2015 at 04:16:13PM -0500, J. Bruce Fields wrote:
> 
> Right, but look at the case above carefully again--it's *much* more
> special than the one the container people hit.
> 
> You can absolutely still represent weird modes like 026 with a Richacl
> and it will deny permissions in the traditional way.
> 
> What you can't do is represent the above POSIX ACL.
> 
> This is a case that you can *only* hit with POSIX ACLs (not with mode
> bits).  And that's because the POSIX ACL is doing something bizarre and
> useless that I've never seen any other ACL system do (denying read and
> write together when each would be permitted separately).
> 
> Using the usual "if a tree fell in a forest and nobody heard it..."
> criterion, I think this change would be unlikely to cause us trouble.

Agreed. I scratched my head and simply couln't think of a
case where this could affect security of the system - only
backwards bug compatibility.

RE: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Frank Filz]

> On Tue, Jan 13, 2015 at 04:16:13PM -0500, J. Bruce Fields wrote:
> >
> > Right, but look at the case above carefully again--it's *much* more
> > special than the one the container people hit.
> >
> > You can absolutely still represent weird modes like 026 with a Richacl
> > and it will deny permissions in the traditional way.
> >
> > What you can't do is represent the above POSIX ACL.


Of course implementing 026 requires use of DENY ACEs, though the group DENY
ACEs could be ordered after all group ALLOW ACEs, thus 026 would operate as
expected, while GROUP 501:r--, GROUP 502:-w- would allow a user who is a
member of both groups RW access since the ACL would be:

GROUP 501: Allow r--
GROUP 502: Allow -w-
GROUP 501: Deny -wx
GROUP 502: Deny r-x

Sorting of the user ACEs isn't important since a process can only belong to
one user.

> > This is a case that you can *only* hit with POSIX ACLs (not with mode
> > bits).  And that's because the POSIX ACL is doing something bizarre
> > and useless that I've never seen any other ACL system do (denying read
> > and write together when each would be permitted separately).
> >
> > Using the usual "if a tree fell in a forest and nobody heard it..."
> > criterion, I think this change would be unlikely to cause us trouble.
> 
> Agreed. I scratched my head and simply couln't think of a case where this
> could affect security of the system - only backwards bug compatibility.

Yea, I can't think of anything since you can always open two file
descriptors.

Frank

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Jan Kara]

On Tue 13-01-15 16:16:13, J. Bruce Fields wrote:
> On Tue, Jan 13, 2015 at 10:04:40PM +0100, Jan Kara wrote:
> > On Tue 13-01-15 12:40:29, 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.
> > > > 
> > > > 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.
> > > 
> > > If we modified the behavior to permit O_RDWR in this case, would that
> > > cause anyone a problem?
> >   As others noted, this changes user visible behavior and I don't think we
> > can do that. In the discussion about user namespaces, we for example
> > specifically disallowed unpriviledged process to drop some group membership
> > exactly because it can actually result in process suddently being able to
> > access some files and reportedly there are setups which are using group
> > membership to *restrict* access.
> 
> Right, but look at the case above carefully again--it's *much* more
> special than the one the container people hit.
> 
> You can absolutely still represent weird modes like 026 with a Richacl
> and it will deny permissions in the traditional way.
  Ah, OK. You are right that Rich ACLs can express the use of a group to
restrict permissions.

> Using the usual "if a tree fell in a forest and nobody heard it..."
> criterion, I think this change would be unlikely to cause us trouble.
  On a second thought I agree.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Andreas Gruenbacher]

On 01/13/2015 08:53 PM, Frank Filz wrote:
>> 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 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...)

Yes, sorry.

Andreas

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Andreas Gruenbacher]

On 01/13/2015 10:31 PM, Jan Kara wrote:
> On Tue 13-01-15 16:16:13, J. Bruce Fields wrote:
>> On Tue, Jan 13, 2015 at 10:04:40PM +0100, Jan Kara wrote:
>>> On Tue 13-01-15 12:40:29, J. Bruce Fields wrote:
>>>> If we modified the behavior to permit O_RDWR in this case, would that
>>>> cause anyone a problem?
>>>    As others noted, this changes user visible behavior and I don't think we
>>> can do that. In the discussion about user namespaces, we for example
>>> specifically disallowed unpriviledged process to drop some group membership
>>> exactly because it can actually result in process suddently being able to
>>> access some files and reportedly there are setups which are using group
>>> membership to *restrict* access.
>>
>> Right, but look at the case above carefully again--it's *much* more
>> special than the one the container people hit.
>>
>> You can absolutely still represent weird modes like 026 with a Richacl
>> and it will deny permissions in the traditional way.
>    Ah, OK. You are right that Rich ACLs can express the use of a group to
> restrict permissions.
>
>> Using the usual "if a tree fell in a forest and nobody heard it..."
>> criterion, I think this change would be unlikely to cause us trouble.
>    On a second thought I agree.

I really don't think that changing the existing POSIX ACL behavior is an 
option here, or that representing POSIX ACLs as richacls internally 
makes a lot of sense. We'll be much better off having both models side 
by side.

Converting existing POSIX ACLs into richacls, for example for converting 
an entire file system, possibly offline, is relatively simple and 
straight forward -- and will be needed -- with the caveat that 
permissions will then start to accumulate.

Converting richacls into POSIX ACLs may occasionally be needed when 
migrating something back as well, but this operation is lossy in 
general, likely slow, there could be different policies like failing or 
dropping permissions when something cannot be represented exactly. By 
representing POSIX ACLs as richacls internally, that more complicated 
conversion would be needed all the time, even in the kernel, though.

Thanks,
Andreas

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Jeff Layton]

On Wed, 14 Jan 2015 09:53:10 +0100
Andreas Gruenbacher <agruenba@redhat.com> wrote:

> On 01/13/2015 10:31 PM, Jan Kara wrote:
> > On Tue 13-01-15 16:16:13, J. Bruce Fields wrote:
> >> On Tue, Jan 13, 2015 at 10:04:40PM +0100, Jan Kara wrote:
> >>> On Tue 13-01-15 12:40:29, J. Bruce Fields wrote:
> >>>> If we modified the behavior to permit O_RDWR in this case, would that
> >>>> cause anyone a problem?
> >>>    As others noted, this changes user visible behavior and I don't think we
> >>> can do that. In the discussion about user namespaces, we for example
> >>> specifically disallowed unpriviledged process to drop some group membership
> >>> exactly because it can actually result in process suddently being able to
> >>> access some files and reportedly there are setups which are using group
> >>> membership to *restrict* access.
> >>
> >> Right, but look at the case above carefully again--it's *much* more
> >> special than the one the container people hit.
> >>
> >> You can absolutely still represent weird modes like 026 with a Richacl
> >> and it will deny permissions in the traditional way.
> >    Ah, OK. You are right that Rich ACLs can express the use of a group to
> > restrict permissions.
> >
> >> Using the usual "if a tree fell in a forest and nobody heard it..."
> >> criterion, I think this change would be unlikely to cause us trouble.
> >    On a second thought I agree.
> 
> I really don't think that changing the existing POSIX ACL behavior is an 
> option here, or that representing POSIX ACLs as richacls internally 
> makes a lot of sense. We'll be much better off having both models side 
> by side.
> 
> Converting existing POSIX ACLs into richacls, for example for converting 
> an entire file system, possibly offline, is relatively simple and 
> straight forward -- and will be needed -- with the caveat that 
> permissions will then start to accumulate.
> 
> Converting richacls into POSIX ACLs may occasionally be needed when 
> migrating something back as well, but this operation is lossy in 
> general, likely slow, there could be different policies like failing or 
> dropping permissions when something cannot be represented exactly. By 
> representing POSIX ACLs as richacls internally, that more complicated 
> conversion would be needed all the time, even in the kernel, though.
> 

FWIW, at the last LSF we had a discussion around richacls and Aneesh
was present. The tentative decision at that time was that filesystems
should store _either_ richacls or posix acls, and that decision should
be made at fs creation time.

If you need to convert to the other scheme, then the understanding was
that you'd either recreate the filesystem, or potentially do some sort
of in-place conversion with a specialized tool.

I think aiming for that sort of scheme makes the most sense as it
covers the vast majority of use-cases and keeps undue complexity out of
the kernel.

-- 
Jeff Layton <jlayton@primarydata.com>

Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[J. Bruce Fields]

On Wed, Jan 14, 2015 at 07:01:35AM -0500, Jeff Layton wrote:
> On Wed, 14 Jan 2015 09:53:10 +0100
> Andreas Gruenbacher <agruenba@redhat.com> wrote:
> > I really don't think that changing the existing POSIX ACL behavior is an 
> > option here, or that representing POSIX ACLs as richacls internally 
> > makes a lot of sense. We'll be much better off having both models side 
> > by side.

OK, fair enough, it may not be worth the trouble.

> > 
> > Converting existing POSIX ACLs into richacls, for example for converting 
> > an entire file system, possibly offline, is relatively simple and 
> > straight forward -- and will be needed -- with the caveat that 
> > permissions will then start to accumulate.

Please don't say it that way or people are going to think we're not
handling cases like mode 026--we should definitely insert DENYs as as
necessary.  So the only inaccuracy is that weird corner case with group
ACEs.  Which is worth a footnote, sure, but that's all.

--b.

> > Converting richacls into POSIX ACLs may occasionally be needed when 
> > migrating something back as well, but this operation is lossy in 
> > general, likely slow, there could be different policies like failing or 
> > dropping permissions when something cannot be represented exactly. By 
> > representing POSIX ACLs as richacls internally, that more complicated 
> > conversion would be needed all the time, even in the kernel, though.
> > 
> 
> FWIW, at the last LSF we had a discussion around richacls and Aneesh
> was present. The tentative decision at that time was that filesystems
> should store _either_ richacls or posix acls, and that decision should
> be made at fs creation time.
> 
> If you need to convert to the other scheme, then the understanding was
> that you'd either recreate the filesystem, or potentially do some sort
> of in-place conversion with a specialized tool.
> 
> I think aiming for that sort of scheme makes the most sense as it
> covers the vast majority of use-cases and keeps undue complexity out of
> the kernel.
> 
> -- 
> Jeff Layton <jlayton@primarydata.com>

RE: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Frank Filz]

> On Wed, Jan 14, 2015 at 07:01:35AM -0500, Jeff Layton wrote:
> > On Wed, 14 Jan 2015 09:53:10 +0100
> > Andreas Gruenbacher <agruenba@redhat.com> wrote:
> > > I really don't think that changing the existing POSIX ACL behavior
> > > is an option here, or that representing POSIX ACLs as richacls
> > > internally makes a lot of sense. We'll be much better off having
> > > both models side by side.
> 
> OK, fair enough, it may not be worth the trouble.

That certainly makes life a lot simplere.

> > > Converting existing POSIX ACLs into richacls, for example for
> > > converting an entire file system, possibly offline, is relatively
> > > simple and straight forward -- and will be needed -- with the caveat
> > > that permissions will then start to accumulate.
> 
> Please don't say it that way or people are going to think we're not
handling
> cases like mode 026--we should definitely insert DENYs as as necessary.
So
> the only inaccuracy is that weird corner case with group ACEs.  Which is
worth
> a footnote, sure, but that's all.

Yes, definitely, any conversion tool should make a best effort. A conversion
tool could also have options to direct how it translates certain tricky
constructions. So if the sysadmin knows groups are used to remove
permissions, then the conversion tool could be directed to insert a DENY ACE
after every group ACE (such a user SHOULD NOT have this construct anyway, it
wouldn't make sense).

> > > Converting richacls into POSIX ACLs may occasionally be needed when
> > > migrating something back as well, but this operation is lossy in
> > > general, likely slow, there could be different policies like failing
> > > or dropping permissions when something cannot be represented
> > > exactly. By representing POSIX ACLs as richacls internally, that
> > > more complicated conversion would be needed all the time, even in the
> kernel, though.

Hmm, poor cp and tar (and other tools) will be thrown into shark infested
waters... I assume the initial caveat will be that anything that copies a
file from a filesystem that uses POSIX to a filesystem that uses RICHACL or
visa versa will NOT copy the ACL.

> > FWIW, at the last LSF we had a discussion around richacls and Aneesh
> > was present. The tentative decision at that time was that filesystems
> > should store _either_ richacls or posix acls, and that decision should
> > be made at fs creation time.
> >
> > If you need to convert to the other scheme, then the understanding was
> > that you'd either recreate the filesystem, or potentially do some sort
> > of in-place conversion with a specialized tool.
> >
> > I think aiming for that sort of scheme makes the most sense as it
> > covers the vast majority of use-cases and keeps undue complexity out
> > of the kernel.

Yea, that sounds good.

Frank

Re: [LSF/MM ATTEND] Richacls

[Steve French]

On Mon, Jan 12, 2015 at 3:06 PM, Andreas Gruenbacher
<agruenba@redhat.com> wrote:
> Hello,
>
> I would like to discuss the status and next steps for completing
> richacl support (http://en.wikipedia.org/wiki/Richacls) in
> the vfs, local file systems, nfs, cifs.
>
> Right now, we don't have kernel support for a file permission
> model powerful enough to support both POSIX permissions and
> NFSv4 / CIFS access control lists at the same time.  As a result,
> support for the NFSv4 and CIFS permission models is very limited,
> and permission wise, Linux is neither a very good client nor
> server to other systems.  For example, the permission to only
> append to a file or to take ownership of a file cannot be
> represented.  When files are copied across systems, file
> permissions change or are lost.

I strongly am interested in this topic, and the related topic
of whether any of the more recent extensions to the SMB3
ACL model ("DAC", to allow richer ACL semantics, and "claims
based ACLs") should be visible to the kernel or whether
it is adequate to enforce only in user space (in Samba
and presumably Apache).




-- 
Thanks,

Steve