Subject: [nfsv4] NFSv4.1 6.2.1.5. ACE Who

From: "Peter Varga" <[email-masked]>
Date: Fri, 29 Jun 2007 12:26:01 -0400

The special "Who" identifiers listed in section of 6.2.1.5 of draft11
are currently simply carried over from RFC3530. I believe these were
originally based on Windows built-in security principals dating back to
early versions of Windows NT. This list has since grown. See attached
screenshot. The list has grown even larger still with Windows Vista.

Other than "OWNER", "GROUP", "EVERYONE", do these have any meaning for
Unix? "OWNER", "GROUP", "EVERYONE" are understood without consulting
translation tables. Similarly, the others have to be also. For instance,
if "INTERACTIVE@" is allowed read/write access to a file, and no other
ACEs are defined, then that file can only be read/modified by users who
are on physical terminals on the server. Thus, the meaning of
"INTERACTIVE@" must be understood and evaluated by the client. It must
have this concept built into the security part of the operating system.
I don't believe this is the case for any UNIX O/S. Please correct me if
I'm wrong. With Solaris 10 (NFSv4.0) client, if our Windows server
returns "SERVICE@" (for example) in the ACE, Solaris shows errors in an
ls -al. Clearly, it does not understand it. Thus, it is impractical for
our server to return any of these special names in ACEs. Our server
currently allows mapping these Windows built-in principals to some GID
in order to avoid returning them in NFSv4.

Should the spec be updated to reflect Microsoft's new additions? As
Microsoft continues to add more built-in principals with each version of
Windows, the list in NFSv4 will keep becoming outdated. The section
about these special identifiers needs to be clarified for client/server
behavior in terms of interpreting them, specifically on how to behave if
the security component of the O/S does not have a way to interpret the
special names. If these special names can only be understood by Windows,
and there is no intention to implement their functional purpose on UNIX,
there's no reason to include them in NFSv4.1.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4