.de Sc \\s-1\\$1\\s0\\$2 .. .ds cA 387 .ds aR \s-1PSARC/2009\s0 .LP .so ../../amac .Co .ds LF \fI\*(aR/\*(cA\fP .ds RF \fICopyright 2009 Sun Microsystems\fP .if n .ds CF .IP \fBSubject:\fP 15 Pathname Reparse Points .IP "\fBSubmitted by:\fP" 15 Afshin Salek .IP \fBFile:\fP 15 \*(aR/\*(cA/opinion.ms .IP \fBDate:\fP 15 August 5th, 2009 .IP "\fBCommittee:\fP" 15 Glenn Skinner (opinion written by Mark Martin), Garrett D'Amore, Mark Carlson, Richard Matthews, Sebastien Roy. .IP "\fBProduct Approval Committee:\fP" 15 Solaris PAC .br solaris-pac-opinion@sun.com .pn 2 .NH Summary .LP This is one of a series of projects under the umbrella case: PSARC 2009/399 "Reparse Points and Referrals Umbrella Case". There are situations where a mechanism is needed to reflect the concept that data is not present at a particular path, but can be found in some alternate location(s). Examples include "referrals" used to build unified name spaces in NFSv4.x and SMB, and data relocation in HSM systems. A "reparse point" is defined as the marker for a namespace redirection and a container for the metadata to specify where the target of this redirection is. Reparse points are intended to be a general mechanism for location redirection and as such the file system that contains them is not cognizant of the reparse point format or content. Services that use reparse points know how to interpret and use the stored data. .NH Decision & Precedence Information .LP The project is approved as specified in reference [2]. .LP The project may be delivered in a minor release of Solaris. .LP .NH Interfaces .LP The project exports the following interfaces. .if n .ne 8 .if t .ne 3 .TS H box; c s s l | l | l. Interfaces Exported _ Interface Classification Comments _ .TH VOP_LOOKUP, fop_lookup Consolidation Private T{ Added new argument: vattr_t *vap T} XAT_REPARSE Consolidation Private T{ Reparse extensible attribute T} T{ symlink context syntax for Reparse points T} Committed reparse_kderef Consolidation Private T{ Reparse kernel routines T} reparse_init reparse_parse reparse_free reparse_init Consolidation Private T{ Reparse library routines T} reparse_parse \^ \^ reparse_add \^ \^ reparse_remove \^ \^ reparse_unparse \^ \^ reparse_free \^ \^ reparse_create \^ \^ reparse_delete \^ \^ reparse_deref \^ \^ reparse_plugin_ops_t Consolidation Private T{ Reparse plugin ops T} /usr/lib/reparse/reparsed Consolidation Private T{ Reparse daemon T} /usr/lib/libreparse.so Consolidation Private Reparse library /var/run/reparse_door Consolidation Private T{ User space door T} T{ svc: /system/filesystem/reparse T} Uncommitted SMF Service .TE .NH Opinion .LP .NH 2 POSIX Conformance .LP The key issue in the case was the question of whether or not the presence of a reparse point affects POSIX conformance. The problem is that a POSIX-conformant application could create a symlink whose contents match the reparse point syntax. Subsequently, that, or another POSIX-conformat, application could do a pathname traversal through that symlink, have it be treated as a reparse point (thereby inducing its interpretation, perhaps as an NFS referral), and experience normal symlink semantics (either a traversal failure or having the traversal resolve to a file whose name matches the reparse point's contents). The project team noted that this situation can only arise when a non-POSIX conformant service (such as NFS or SMB) has control over the part of the file system name space containing the reparse point. The team further claimed that this involvement of a non-POSIX copnformant service removes the traversal from the scope of activities subject to POSIX requirements. After some discussion, the committee accepted this argument. .NH 2 Follow-on Consumers .LP The question was raised whether this case should have a dependency on one of the follow-on cases mentioned in 2009/399 [Reparse Points and Referrals Umbrella Case] to ensure that a consumer of this project's deliverables is delived in tandem with this projhect itself. The project team argued that this case provides value in and of itself, and the committee members accepted this argument .NH 2 Specification Changes .LP .NH 3 Release Binding .LP The release binding changed from update to minor. This change was triggered by observing that the change to the signature of VOP_LOOKUP() was not suitable for an update binding. .NH 3 Stability Level of the Reparse Format .LP The stability level of the in-symlink reparse point format changed from Committed Private to Committed. This change was motivated by noting that there should be a way to know that one has not inadvertenty created a reparse point when creating a symlink. .NH 2 Reparse Point Enable/Disable .LP The committee discussed whether adding some mechanism to enable and disable reparse points, perhaps on a file system-wide basis would help alleviate the compatibility concerns illustrated by the previous point. The consensus among the committee and project team members was that this proposed cure was worse than the disease. .NH 2 Other Minor Clarifications .LP There were various other minor points of confusion (some relating to terminology). Where appropriate, the project team updated the specification to incorporate the clarifications. .NH Minority Opinion(s) .LP None. .NH Advisory Information .LP .NH 2 Auditing in Follow-on Projects .LP Any follow-on project that provides a service employing reparse points should verify that referral data provided in response to triggering a reparse point is properly audited on the client system that triggered the reparse point. .NH 2 Upcoming NFS Referrals Case .LP As part of preparing the materials for the ARC review of the upcoming NFS referrals case, committee members advise the project team to provide a step by step account of what happens when pathname traversal encounters a referral. .NH Appendices .NH 2 Appendix A: Technical Changes Required .LP None. .NH 2 Appendix B: Technical Changes Advised .LP None. .NH 2 Appendix C: Reference Material .LP Unless stated otherwise, path names are relative to the case directory \*(aR/\*(cA. .IP 1. Onepager. .br File: 20090709_afshin.salek .IP 2. Project Specification. .br File: final.materials/reparse_spec.txt .IP 3. Commmitment Minutes. .br File: commitment-notes .IP 4. PSARC 20 Questions. .br File: final.materials/reparse_20q.txt .IP 5. Global namespace: The future of distributed file server management. .br http://findarticles.com/p/articles/mi_m0BRZ/is_2_23/ai_98709766/ .IP 6. Implementation Guide for Referrals in NFSv4. .br http://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00 .IP 7. DFS Technical Reference. .br http://technet.microsoft.com/en-us/library/cc757042%28WS.10%29.aspx