ACL oddity

[J. Bruce Fields]

On Wed, Aug 15, 2007 at 01:33:30PM -0400, bfields wrote:
> On Wed, Aug 15, 2007 at 10:55:17AM -0400, Steve Gaarder wrote:
> > When a user who is a member of group web434 logs into an NFSv3 client 
> > (also Red Hat Enterprise 4) and creates a file, everything is fine:
> > 
> > # file: frobozz
> > # owner: gaarder
> > # group: web434
> > user::rw-
> > group::rwx                      #effective:rw-
> > group:web434:rwx                #effective:rw-
> > mask::rw-
> > other::r--
> > 
> > But when I do this on a machine using NFSv4 with sec=krb5 (RHEL4 again), 
> > this happens:
> > 
> > # file: foo
> > # owner: gaarder
> > # group: web434
> > user::rw-
> > group::rwx                      #effective:r--
> > group:web434:rwx                #effective:r--
> > mask::r--
> > other::r--
> > 
> > The difference is that the "mask" parameter becomes read-only, which 
> > shuts off write access to groups.  The umask in both cases is 022.  Ideas?
> 
> That's odd.  The code involved in creation of a new file isn't really
> that different between v3 and v4, and there aren't any ACLs on the wire
> until you ask for them (only a mode is sent--the default ACL application
> and so on is done by generic VFS code somewhere).

Hm.  Reading that again.  So the difference is that in the v4 case the
umask was applied, whereas in the v3 case it wasn't?

When creating a file in a directory with a default acl, the umask is
supposed to be ignored.  So the v3 result is the correct one.

There's no way to distinguish the umask and open mode on the wire, so
it's not obvious how to do this....  Grepping through the git logs, I
see there's an explanation in 055ffbea05; the client actually does this
manually by querying the default acl on the directory and setting the
mode appropriately.

I don't think there's a reasonable way to do that in v4, since the acls
used in v4 aren't really posix acls at all.  So I suspect we're just
going to end up living with that difference.

--b.