IAM ====== Name: Pathname Reparse Points Submitter: Afshin Salek Owner: Glenn Skinner Intern: Mark Martin Exposure: open SUMMARY ======= 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. ISSUES ====== Issues for inception review on 2009-08-05 mam-01 In the Interface table: "Note: There is no need to define a name in the file system to support a user space door service that is called from the kernel, and not defining a name avoids potential security concerns. Thus the door interface is private to the implementation and not mentioned in the interface table." Does this mean that the door name is randomly generated? A cursory source inspection will reveal the name, so what are the security concerns? It may not be customary to report door names, but I'm curious what the motivation is. Response: You can create a door name in var/run, which is a means for a door client to locate a door server. In the case of a kernel door client, it can lookup the door handle directly, it doesn't need any name in the file system. If you put a name in /var/run unnecessarily, that opens an avenue for a potential attack because people know what name to use to access the door server. It seems better to not provide a name in the file system, which ensures that user space applications have no means to access the door server. Amended Response: I've been reconsidering this discussion and I think we may want to have a door file in /var/run. As things are now, reparsed must pass the door fd to kernel modules, which means there is a specific relationship between reparsed and consumers of the reparse API: reparsed must open the device and issue an ioctl. Also, only kernel components can use the reparse API because user space applications can't find the door. I think it would be good to remove these dependencies and limitations, and I can't think of any security issues around applications asking reparsed to exchange the svc_data. It doesn't provide anything that the application couldn't have gotten by going directly to the backend referral service. The door file would be /var/run/reparse_door. mam-02 Reparse CLI consolidation private versus uncommitted? Does this unnecessarily lower usability expectations? Are we prepared not to give the user a well known way to manage these links from CLI? Response: There are no user space consumers outside of the project. Perhaps we should remove the test program description from the spec. Amended Response: I'd also like to remove the rp test program from the spec. It's not a deliverable and it shouldn't be documented in the case. dwc-1 reparse_20q.txt, Q1, 2nd bullet: Does saying "The exposure is OpenSolaris" mean that this project will not be integrated into Solaris next? Response: The intent is to deliver to Nevada, which should deliver into both SolarisNext and OpenSolaris. If that's not the case, PSARC guidance is welcome here. dwc-2 reparse_20q.txt, Q1, 3rd bullet: Is this project really suitable for a patch? It would seem that a project that alters the footprint of VOP_LOOKUP() would need a major release binding. Response: There is no plan to backport this change. I believe that this case should have minor binding but PSARC guidance is welcome. dwc-3 reparse_20q.txt, Q1, last bullet: I thought this question was asking how this case (PSARC/2009/387) relates to other arc cases (e.g., PSARC/2009/399); not what case number is assigned to this case??? Response: Nothing in this project should result in a misalignment with existing or proposed ARC cases. dwc-4 reparse_20q.txt, Q2, 1st bullet: I didn't find any documents named "section 4 and 5" in the case directory nor in the inception.materials directory in the case directory??? This is a recurring problem in this document. There are lots of files in the case directory and sub-directories, but this document seems to imply that all of the case materials are in a single, unnamed file. Response: The reference is to sections 4 and 5 of reparse_spec.txt, which appears in the inception.materials directory. Other than reparse_20q.txt, reparse_spec.txt is the only other document in the inception.materials directory. All such references in reparse_20q.txt are to inception.materials/reparse_spec.txt dwc-5 reparse_spec.txt, section 3, - list: Contray to what is stated here: - POSIX rules are broken. - If there is a file (whether it is a regular file, a directory, or anyother symlink doesn't matter) named "@{REPARSE@{a:b}}" and a symlink in the same directory is later created that points to that file, you say that the symlink will be created as a regular symlink. That matches POSIX requirements. If I create these files in the other order, you say that the symlink will be magically turned into a referral. That violates POSIX requirements. If I create an archive (cpio, tar, star, etc.) that contains both the file and the symlink pointing to it, the order in which they were stuck in the archive will determine whether extracting those files from the archive works or fails. That violates POSIX requirements. As stated in my email (dated Sat Jul 11 12:19:38 2009), you could file an interpretation request to try to get POSIX and the SUS to make the behavior of symlinks whose contents start with "@{" unspecified or implementation-defined. That would allow what you are proposing (as well as BSD magic links) without having to get the standards community to fully specify the behavior of referrals or magic links. Without an interpretation request, someone like Geoff would love to add a new test to the UNIX branding test suite to deny a brand for non-standard symlink behavior. Response: Regardless of whether or not XAT_REPARSE has been set, the object still appears as, and behaves exactly like, a symlink to all local applications. There is no way for them to distinguish it from any other symlink. The order of creation makes no difference to archivers (cpio, tar, star, etc.): they will work as they do today (they will not be using the proposed reparse API). Applications that use POSIX calls will not be affected: creating a symlink named "@{REPARSE@{a:b}}" that points to a file will succeed and behave like a symlink to all local POSIX applications. Although not applicable to this reparse points case, the team understands the potential for an application to see a different behaviour when run over NFS or SMB in the presence of a referral service. Can you provide guidance on how to go about submitting and pursuing a standards interpretation change request? dwc-6 reparse_spec.txt, section 4.1: The standards are clear that symlink() and readlink() are used to create and read the contents of symbolic links; not referrals or magic links. Response: The symlink()/readlink() behavior will not be affected by this case. Referrals are an interpretation of a symlink by non-POSIX services, such as NFS and SMB. dwc-7 reparse_spec.txt, section 4.3: The statement that reparse points will be handled correctly by existing applications is only true as long as a file with a name specified by the of the contents of the symlink does not exist when the the symlink is created and is never created after that. Response: We believe that reparse points will be handled as expected by existing local applications in all cases. dwc-8 reparse_spec.txt, section 4.3: Doesn't changing the footprint of VOP_LOOKUP mean that all existing code that uses that interface has to change at the same time as the putback for this project? How will this be coordinated with external filesystem projects when this is installed as a patch? Response: Yes, the changes will be pushed at the same time. We plan to handle it in the same way that it was handled previously, for example, PSARC 2007/218 and 2007/227. dwc-9 reparse_spec.txt, sections 5.1 and 5.2: What does "Functions returning int will return zero on success or a non-zero errno value on failure." mean? Is it: 1. 0 will be returned on success; -1 will be returned on error and the external variable errno will be set to indicate which error occurred, or 2. 0 will be returned on success; an error value from will be returned on failure and the external variable errno will not be changed? Which error values will be used by these routines and under what conditions? Response: There is no mention of setting external variable errno. These functions will return 0 on success or they will return an error value from sys/errno.h on failure. Other than EOVERFLOW, which is documented, possible error values returned will most likely be EINVAL or ENOMEM. EINVAL will indicate an invalid parameter or reparse point format. ENOMEM will indicate that the API was unable to allocate memory required to complete the operation. dwc-10 reparse_spec.txt, section 5.1: Do work correctly, don't archivers have to be modified to use reparse_create() and reparse_delete() when moving file hierarchies and extracting file hierarchies from archives if archived symlinks were reparse points when they were archived? Response: No, existing applications must not be modified to use the reparse API. Making such a change would invalidate the assumptions and assertions on which this case is predicated. dwc-11 reparse_spec.txt, section 5.3: The amended response to issue mam-02 in the issues file says that you'd like to remove rp from the spec. Why is it still here? Response: The spec has not yet been updated to avoid potential confusion from receiving comments on multiple revisions of the case materials prior to the inception review. dwc-12 reparse_spec.txt, section 5.9: Why aren't auditing requirements for adding and removing reparse points similar to mount and unmount operations? Response: Reparse points provide a basic infrastructure on which usable services can be created - the reparse implementation will not interpret the content of a reparse point beyond basic format validation. It seemed more useful to implement auditing within the services built on reparse points, such as referrals, since those services will interpret the content. dwc-13 reparse_spec.txt, section 6: But, unlike symlinks, reparse points can redirect access to files on foreign hosts. Doesn't this affect the security model? Response: This question seems to apply to referrals rather than reparse points since nothing in the reparse point implementation will provide any redirection. As with symlinks, all security for referrals is handled at the destination. Referrals simply point at an alternate location and it is up to the client to select, go to and attempt access at an alternate location. The security or access control of the thing being referred to is not known or relevant to the local referral service. dwc-14 reparse_spec.txt, section 7: What is "Committed Private"? I thought Private classifications were one of "Contracted Private", "Project Private", and "Consolidation Private". Response: This should be: Committed, Consolidation Private. seb-01 The interface table in section 7 makes a reference to "reparse token syntax". This is the first reference to the tern "token". What is this? Is this the syntax of the reparse data displayed as the symbolic link target? seb-02 What is the reasoning behind making the reparse data format Committed Private rather than some form of Public? (assuming that "reparse token" means "reparse data"). seb-03 What does ls -L do with reparse point symlinks? ged-01 I'm concerned that the reparse points create a situation where different views of the filesystem are present in the local filesystem from what is exported via the NFS. It seems like the server should have a way for local users to access the data in the same fashion that remote users do. ged-02 Is there a way to specify that support for reparse/referrals will be used or not (maybe that's an issue for the NFSv4 and SMB cases.) ged-03 If we had "local" referrals, resolved by the kernel, then we could use referrals to solve other problems, such as the isaexec problem. Any thoughts on this? ged-04 On the referral syntax, how will the tags and values (and the semantics of them) be tracked? Individual PSARC cases? ged-99 The token syntax seems incredibly unwieldy. While I understand that we need to avoid collisions, making heads or tails of the syntax is going to be "difficult". THE NEXT STEP ============= spec update Minor binding refer to umbrella check with Rich Brown about contracts Reparse to be committed rather than committed private Change on name for reparse points Error returns clearer in documentation opinion dwc-5 posix future cases need to test auditing vote Glenn Skinner yes Kais Belgaied non participating Sebastien Roy yes Mark Carlson yes mark Martin yes Garrett D'Amore yes Rick Matthews yes Gary Winiger non participating approved