On Oct 20, 2007, at 1:56 PM, Ben Rockwood wrote: > I'm curious if there is a NFSv4 roadmap beyond whats being done for > pNFS. In particular, I'm curious if features of NFSv4 that haven't > been implemented ever will be, such as LIPKEY support, NFS logging > or improved fsid handling for psuedo-filesystems. > > I see LIPKEY as interesting by providing an alternative to > Kerberos. One of the clear objectives of NFSv4 was playing nice on > the Internet and right now thats not practical. The Solaris > implementation seems like a Kerberos or nothing environment; the > reading I've done on AUTH_DH isn't terribly reassuring. PSARC > 1999/289 made it sound as though it would come a later time.
Yes, LIPKEY would certainly be a good addition and one of the main reasons why the LIPKEY/SPKM-3 combination was specified in NFSv4. In the course of implementation, the UMmich/CITI team found a few issues with the SPKM-3 specification that needed clarification. As a result of the following discussion within the IETF, there has been a proposal to replace SPKM-3 with a "better" alternative in that there are some opinions that SPKM-3 may be inappropriate for the use proposed. The proposal with the most interest at this point is: "Public Key Cryptography Based User-to-User Authentication - PKU2U" http://www.ietf.org/internet-drafts/draft-zhu-pku2u-02.txt Given the abstract from that document: This document defines the public key cryptography based user-to-user authentication protocol - PKU2U. This mechanism provides security services in peer to peer networking environments without requiring a trusted third party. Furthermore, the binding of PKU2U for the Generic Security Service Application Program Interface (GSS-API) per RFC2743 is defined based on RFC4121. It appears to be a great match for the needs of NFSv4 in the scenario you identified. So, given the issues with SPKM-3, the lack of broad adoption of that protocol (UMich/CITI and an IBM implementation are the only ones I know of), there are non current plans to provide the SPKM-3/LIPKEY mechanisms in OpenSolaris for use by NFSv4. I am hopeful to see progress with the PKU2U mechanism but to be honest, there is more interest than funding for the effort at this point within the Sun portion of the OpenSolaris community -- maybe there is help/interest available from the broader OpenSolaris community. > > Regarding fsid handling, the Linux NFSv4 implemenation makes it > easy to explicitly define fsid's to build psuedo-filesystems, > however I see no way using the Solaris implementation to manage these. Yes, NFSv4 does give one a lot of rope. The current Linux server flexibility has certainly provided for a series of interop issues given that the NFSv3 and NFSv4 view of the server's filesystems can differ (easily). This is likely more a result of the choices made in the implementation of the feature rather than the NFSv4 protocol itself. We obviously took the conservative route in the initial NFSv4 work -- our goal was to minimize the administrative impact with the delivery of NFSv4 to Solaris. As the NFSv4 market matures, we have seen an interest in building a server-to-server protocol to manager braoder filesystem namespaces. We have also seen a maturing of the NFS clients to include the mechanism we have termed "mirror mounts". So, while we don't have current plans for expanding the flexibility of building NFS namespaces within OpenSolaris, the day is coming when there will be enough infrastructure around that makes it more interesting than it is today and we should move forward with new administrative mechanisms. As for the logging question, I believe that Lisa covered those issues. Spencer
