Re: [nfsv4] Fwd: New Version Notification for draft-dnoveck-nfsv4-security-04.txt

[[e-mail]]

p. 13: As I said before, I'm not OK with this attempt to pin down ACL
semantics and mode/ACL interactions.  See
https://mailarchive.ietf.org/arch/msg/nfsv4/pbGEGwDvMwknwjsBKsWaK2BRXqc/

p. 20:

	"many clients are built on systems whose only ACL-related API is
	based on the UNIX ACL model."

What clients are you thinking of?  The Linux client, for example, does
provide an NFSv4 ACL API, and we have tools built on it that allow users
to get and set ACLs.

	"it is hard to imagine a server incapable of distinguishing a
	write to an offset within existing file and one beyond it."

Most of the filesystems Linux servers export don't support separate
WRITE and APPEND bits.

	"To do that, requests to set NFSv4 ACLs where the handling for
	these two masks are different for any specified user or group
	are to be rejected with NFS4ERR_ATTRNOTSUPP."

Once upon a time we did have code that rejected any ACL that couldn't be
translated into something storable on our backend filesystems.  It was
painful to use: there's more than one rule governing allowable mask bits
and ALLOW/DENY ordering, and if you mess up, you get one error that
doesn't tell you why.

That's why the Linux server now accepts such ACLs and instead translates
them to something stricter.

You get the guarantee that the ACL won't allow access beyond that you
requested.  And the option of reading back the set ACL gives you at
least some chance of figuring out what happened, where an
NFS4ERR_ATTRNOTSUPP doesn't.

p. 41:

	"The deletion of the file's data is dealt with separately as
	this, like a truncation to length zero, requires
	ACE4_WRITE_DATA."

We can't require write permissions on a file to delete the file.

p. 42:

	"The complexity of the approach without any indication that
	there is a need for such complexity makes me doubtful that
	anything was actually implemented"

I'm pretty sure that section is just a description of what ZFS does, for
what it's worth.

p. 56:

	"Setting only the mode attribute, will result in the access of
	the file being controlled just it would be if the existing acl
	did not exist, with file access decisions as to read made in
	accordance with the mode set."

Neither Linux nor Solaris/ZFS work that way.

p. 61:

	"While the NFSv4.1 provides that many might not need or use, it
	is the one that the working group adopted by the working group,
	and I have to assume that alternatives, such as the withdrawn
	POSIX ACL proposal were considered but not adopted."

Right.  As I understand it, that decision was based in part on the
assumption that it would be possible to map between POSIX and NFSv4
ACLs.  Linux knfsd has been doing that since the beginning.  I don't
agree that this document should now go back and disallow that.

p. 72:

	"The algorithm specified below, now considered the Previous
	Treatment associated with Item #24a, has an important flaw in
	does not deal with the (admittedly uncommon) case in which the
	owner_group has less access than the owner or others have less
	access than the owner-group."

We definitely knew about "reverse-slope" modes and took them into
account.

I'm not entirely sure I understand the algorithm at the end of section
9.3, but I believe it's wrong.  It appears that it would map an ACL
like (ignoring some mask-bit details):

	DENY  OWNER@	 W
	ALLOW EVERYONE@ RW

to the mode r--r--r--.  (Because the OWNER@ ACE applies "in the negative
sense" to the calculation of the group and other bits.)

But the above ACL actually grants write permissions to anyone other than
the file owner, and the correct mode is r--rw-rw-.


(And I also don't like the fact that it ignores named users and groups,
so that, e.g.,

	ALLOW bfields RW

will be mapped to mode 0.)

(I ran out of time here and stopped reading.)

--b.