The pathname reparse points case (2009/387) was approved during today's
PSARC meeting, subject to providing updated materials that reflect
changes agreed to during our discussion.
Here are my notes from the meeting. They describe the required
updates.
-- Glenn
----------------
Notes from the commitment review for PSARC 2009/387 [Pathname Reparse Points]
held on 5-Aug-2009.
The case was approved with members voting as follows:
Kais Belgaied approve
Mark Carlson approve
Garrett D'Amore approve
Richard Matthews approve
Sebastien Roy approve
Glenn Skinner approve
Mark Martin [LSARC] approve
Discussion during the review led to two specification changes:
- 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.)
- 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.)
During the discussion, we identified numerous places where the specification
and the 20 questions document could and should be clarified. The project team
agreed to do so and will deliver a revised specification containing the
clarifications (as well as the changes noted above). In particular:
- The discussion of release binding in the 20 questions document will be
clarified to note that the project intends to deliver into the Nevada
release (which implies that it will also deliver into OpenSolaris.)
- The response to question 1 in the 20 questions document will be revised to
name 2009/399 [Reparse Points and Referrals Umbrella Case] as a related
case.
- The specification's discussion of error return values in sections 5.1 and
5.1 will be clarified to avoid giving the impression that they will set
errno.
- The specification will be updated to make it clear that the check for
existence of a file whose name is identical to the contents of a
to-be-established reparse point appliies only to the create reparse point
call, not to symlink(2).
Other points of note:
- 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.
- We discussed whether adding some mechanism to enable and disable reporse
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.
- We wondered whether this case hould 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 member accepted this argument.
The committee also wished to offer various pieces of advice:
- 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.
- As part of preparing the materials for the ARC review of the upcoming NFS
referrals case, committee members advise that project team to provide a
step by step account of what happens when pathname traversam encounters a
referral.
