ACL oddity

[J. Bruce Fields]

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

Are you querying the ACLs over NFS, or locally on the server?  If the
former, it would be worth logging in to the server and checking the ACL
there to make sure the problem isn't just in the getfacl.

You're positive that creation mode and directory default ACLs are the
same in both cases?

If so, could you get a network trace showing the file creation and the
subsequent query of the ACL?  Just run something like

	tcpdump -s0 -wTMP

then run the test, and send me a copy of TMP.  I'd also like to know the
server kernel version and which libacl patches you're using.

--b.