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

[Rick Macklem <[e-mail]>]

David Noveck wrote:
[> Rick Macklem wrote:
[stuff snipped]
> > Why?
> > Well, my understanding is that APPEND_DATA does not apply to
> > any old Write that happens to start at EOF, but specifically "append-only"
>
> The spec says the contrary.  since there are no NFSv4 append-only operations it
> would not make sense to revise it in line with your understanding.
Ok, yes. I found a Microsoft document that states APPEND_DATA allows writes
that start at EOF.

But what about:
- Setattr of size, where this size is beyond EOF.
  (Not covered by APPEND_DATA, so presumably allowed/denied via
   WRITE_DATA.)
- A Write with an offset > size (ie past EOF).
  (Also allowed/denied via WRITE_DATA.)

So, does WRITE_DATA being set without APPEND_DATA being set make
sense. Not really, but it is allowed by the RFCs, as far as I can see?
It just makes no sense to allow a Write that starts beyond EOF, but not
one that starts at EOF.

So, I understand your position, but I believe (it is not up to me), that
FreeBSD's NFSv4 server will simply choose to continue to ignore APPEND_DATA.

On the PSARC/2010/029 document:
- The author of the FreeBSD NFSv4 ACL code no longer has a copy, either.
   However, he recalls the main item in it was an alternate algorithm for
   converting mode->ACL. The "canonical six" upset Windows, because it
   mixes allow/deny ACEs and apparently Windows likes all the Allow ACEs
   to preceed all the Deny ACEs.
   - This alternate algorithm creates a set of Allow ACEs followed by a set of
      Deny ACEs that are semnatically equivalent to the "canonical six".

I should have a chance to do some NFSv4 ACL testing against a Linux
server on Sunday and will post after that.

rick


file operations. (A POSIX write done on a file opened with the O_APPEND
flag would be one example.)
Since "append-only" file operations do not exist in NFSv4 (as you noted).

true but the server is still able to distinguish writes that extend the file from those that don't.

then ignoring APPEND_DATA seems more correct that assuming it to be
equivalent to WRITE_DATA.

It doesn't make sense to define this mask bit and then ignore it all the time.    When are you supposing it will be looked at?


For example, assume a file with APPEND_DATA allowed, but WRITE_DATA not
allowed that is of size == 0. If APPEND_DATA is sufficient to allow an Open with
OPEN_SHARE_ACCESS_WRITE, then a client could do the following:
- Open the file with OPEN_SHARE_ACCESS_WRITE
  - Write data to the file sequentially (the most common write usage).
--> Not what APPEND_DATA allowed but WRITE_DATA not allowed means,
       from my understanding.

The spec  says that this is allowed.

  *  Servers that do not distinguish between WRITE_DATA and APPEND_DATA
      need to make it clear to clients that support for append-only
      files is not present.  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.

First, given that there is no OPEN_SHARE_ACCESS_APPEND, this applies to
all NFSv4 servers.

No.   It only applies to servers, and they will be common, that do not distinguish WRITE_DATA and APPEND_DATA.   Some if the confusion here resUlts from the fact that, like our old friend owner-override semantics., this is a case in which the handling at OPEN time is different from that at IO time.

Second, although I can understand that this would "make it clear to clients",
there are issues with doing this for systems like FreeBSD, where NFSv4 ACLs
are used locally as well as for the NFSv4 server.
For example, on FreeBSD:
- A setfacl(1) can set any combination of APPEND_DATA, WRITE_DATA or both
  APPEND_DATA and WRITE_DATA for allow/deny when done locally on UFS or ZFS
  file systems.
- A getfacl(1) will show them separately.
If FreeBSD were to enforce the above in the NFSv4 server, the getfacl(1) on a FreeBSD
NFSv4 client would show any combination as above, but the setfacl(1) would fail
for the case where only one of APPEND_DATA/WRITE_DATA is being set.
Users would find this a weird, irritating inconsistency. (As such, it won't be the case
for FreeBSD NFSv4 servers.)

I'd prefer that setting any combination be allowed, but that enforcement of APPEND_DATA
not be done for the NFSv4 server and that APPEND_DATA be handled like other non-enforcible
bits, such as SYNCHRONIZE.

I see your point but note that there is a significant difference between SYNCHRONIZE which is unenforceable since there is no operation to exercise it and APPEND_DATA since there is since people extend files all the time.   As such, APPEND_DATA is enforceable although the server might not enforce the distinction between APPEND_DATA and WRITE_DATA.

If I understand correctly, you are intending to accept an acl that APPEND_DATA and not WRITE_DATA  and then not let the user open the file for write.   I don't know about your users but I would certainly feel that was a "weird, irritating inconsistency".

It seems to me that ace masks were specified including APPEND_DATA to support windows applications with insufficient thought as to how this might  map to the world of UNIX.   Still, we are where we are and have to deal with this.

How would you feel about the following revision of the paragraph for -05?

  *  Servers that do not distinguish between WRITE_DATA and APPEND_DATA
      may need to make it clear to clients that support for append-only
      files is not present.  One way to do that is for requests to set NFSv4 ACLs
      where the handling for these two masks are different for any
      specified user or group to be rejected with     NFS4ERR_ATTRNOTSUPP.





rick

________________________________________
From: nfsv4 <[e-mail]<mailto:[e-mail]>> on behalf of David Noveck <[e-mail]<mailto:[e-mail]>>
Sent: Friday, December 24, 2021 8:49 AM
To: NFSv4; nfsv4-chairs; [e-mail]<mailto:[e-mail]>
Subject: [nfsv4] Fwd: New Version Notification for draft-dnoveck-nfsv4-security-04.txt

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to [e-mail]<mailto:[e-mail]>


I've just posted security-04.   Thanks to Rick Macklem and Chuck Lever who made important suggestions that I hope are correctly addressed in this version.  An rfcdiff with -03 is not small but it is helpful to see what has changed.

As previously discussed, I am proposing that the working group adopt this draft as a working group document.   I expect Brian and Zahed to set the timeline for that discussion.

Please let me know about your suggestions for -05.

---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>
Date: Fri, Dec 24, 2021 at 8:31 AM
Subject: New Version Notification for draft-dnoveck-nfsv4-security-04.txt
To: David Noveck <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>



A new version of I-D, draft-dnoveck-nfsv4-security-04.txt
has been successfully submitted by David Noveck and posted to the
IETF repository.

Name:           draft-dnoveck-nfsv4-security
Revision:       04
Title:          Security for the NFSv4 Protocols
Document date:  2021-12-24
Group:          Individual Submission
Pages:          129
URL:            https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-04.txt
Status:         https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-security/
Html:           https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-04.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-dnoveck-nfsv4-security
Diff:           https://www.ietf.org/rfcdiff?url2=draft-dnoveck-nfsv4-security-04

Abstract:
   This document describes the core security features of the NFSv4
   family of protocols, applying to all minor versions.  The discussion
   includes the use of security features provided by RPC on a per-
   connection basis.

   This preliminary version of the document, is intended, in large part,
   to result in working group discussion regarding existing NFSv4
   security issues and to provide a framework for addressing these
   issues and obtaining working group consensus regarding necessary
   changes.

   When a successor document is eventually published as an RFC, it will
   supersede the description of security appearing in existing minor
   version specification documents such as RFC 7530 and RFC 8881.




The IETF Secretariat