SYSTEM ARCHITECTURE COUNCIL
Platform Software ARC
---------------------------------
PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507.
08-05-2009 MEETING MINUTES
============================================================================
Send CORRECTIONS, additions, deletions to psarc-coord at sun.com.
Minutes are archived in sac.Eng:/sac/export/sac/Minutes/PSARC.
Co-Chair(s):
Garrett D'Amore: Yes
Tim Marsland: no
ATTENDEES - Members: (6 active members)
Kais Belgaied: Yes
Mark Carlson: Yes
Richard Matthews: Yes
Darren Moffat: no (on sabbatical)
Sebastien Roy: Yes
Glenn Skinner: Yes
Bill Sommerfeld: no (on sabbatical)
Gary Winiger: Yes (non participating) (on sabbatical)
STAFF -
Asa Romberger (PM): Yes
ATTENDEES - Interns:
Frank Che no
James Falkner: no (on sabbatical)
Daniel Hain: Yes
Michael Haines: no
Alan Hargreaves: no
Phil Harman: no
Wyllys Ingersoll: no
Darren Reed: no
Dean Roehrich Yes
Ienup Sung: no
Phi Tran Yes
Brian Utterback: no
James Walker no
Mark Martin Yes (external)
Don Cragun Yes (external)
Guests:
-- GUESTS --
Afshin Salek Yes
Alan M Wright Yes
Robert Thurlow Yes
Tai Ngo Yes
Pavan Mettu Yes
Not all names are captured. Please send email to Asa.Romberger at Sun.com, if
you attended the meeting and your name is missing from the list.
---------------------------------------------------------------------------
MEETING SUMMARY:
================
AGENDA
---------------------------------------------------------------------------
Case Anchors: <br>
<A HREF="#case1">Reparse Points and Referrals Umbrella Case
(2009/399)</A> <br>
<A HREF="#case2">Pathname Reparse Points (2009/387)</A> <br>
<A HREF="#case2">Clearview IP Tunneling (2009/373)</A> <br>
===========================================================================
Fast Tracks:
============
Case (Timeout) Exposure Title
2009/388 (08/05/09) open VRRP Update
derail
2009/408 (07/29/09) open resync ssh-agent command with OpenSSH
approved
2009/414 (07/31/09) open AST versions of fold, mktemp,
pathchk, & tty
waiting needs spec
2009/417 (08/05/09) open Deliver libgs.so shared library and
Ghostscript header files
more time
2009/418 (08/04/09) open Kerberos V5 PAC API
approved
Next Meeting:
=============
08/12/2009
10:00-10:10 Open ARC Business (use open dial in above)
10:10-10:55 Open Inception: S10C (2009/253)
Submitter: Gerald Jelinek
Owner: Rick Matthews
Intern: Dean Roehrich
Exposure: open
11:00-11:10 Closed ARC Business (use closed dial in above)
===========================================================================
Case: 2009/410
Name: Datalink Administration from Non-Global Zones
Submitter: Sebastien Roy
Owner: Sebastien Roy
Status: submitted
Exposure: open
SUMMARY
=======
Datalink Administration from Non-Global Zones
ISSUES
======
kb-01 /dev/dld included in /dev of which zones? shared or exclusive?
kb-02 Note for the opinion: I think it is useful to make stress the fact
that the scope of this case is the read/only operation (listing,
getting properties) of the subset of datalinks alowed visibility by
the global zone administrator. Any delegation of control beyond
that
will be defined on a per datalink type, in future cases.
kb-03 The case soemhow extends the meaning of the zonecfg
ip-type=exclusive
to uses of datalinks beyond and even in absence of IP instances.
One wouldn't need to plumb an interface in order to
use the datalink from the zone (through bpf or RDS sockets).
THE NEXT STEP
=============
opinion to include recommendation for improvement on link classification
nomenclature and RFE
Approved
===========================================================================
Case: 2009/387
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 "@{repa...@{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 "@{repa...@{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
<sys/errno.h> 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
===========================================================================
Case: 2009/373
Name: Clearview IP Tunneling
Submitter: Sebastien Roy
Owner: Sebastien Roy
Exposure: open
SUMMARY
=======
This project is a redesign and reimplementation of the IP
tunneling functionality in Solaris. It delivers a GLDv3 driver
(iptun) that implements IP tunnel links atop which IP interfaces
can be plumbed. Tunnel links are managed using new dladm(1M)
subroutines (implemented using new libdladm functions), and IP
interfaces above tunnel links are created using ifconfig(1M) as
with any other type of IP interface.
It replaces the old STREAMS-based IP tunneling implementation
which depended on the ifconfig(1M) command to plumb tunneling
modules (tun, atun, and 6to4tun) atop of /dev/ip or /dev/ip6.
With this project, tunnel links gain functionality common to
other links, including link vanity naming (introduced by
Clearview in PSARC 2006/499), link-layer observability using
traditional observability tools such as Wireshark and snoop(1M),
and the assignment of tunnel links to exclusive stack non-global
zones.
ISSUES
=======
kb-00 It seems to me that we've got two distinct cases here:
(1) datalinks control from non global zones
(2) Clearview IP Tunneling
case (1) brings sufficiently complex architectural changes and is
independant from (2) to warrant a separate case.
Keeping these together also increases the risk of making (1)'s
choices taylored to (2)'s needs.
kb-01 How does information float from the lower IP to the upper one
across
the tun mac provider
- support of LSO
- MTU
I'm thinking of the cases where MTU for example changes because
the outer header for a tunnel get re-routed through an interface
with a different MTU
kb-02 For IPsec tunnels created from the non global zone. I am not
clear on
how the global zone sees the keys for encrypting and/or
authenticating
the payload.
ged-01 ifconfig configuration and syntax. It seems to me that the need to
preserve the legacy functionality might be overstated here. I
understand that some customer confusion may occur, but given the
"break" inherent in OpenSolaris vs. Solaris 10, maybe the legacy
baggage can just be elided? At a minimum I'd like to see the
legacy
syntax marked Obsolete and planned for removal.
(I'm thinking the things most likely to break are tools such as
punchin.)
ged-99 speaking of punchin, will it be modified to use the new dladm
subcommands?
VOTE
====
Approve -
Sebastien Roy
Glenn Skinner
Kais Belgaied
Mark Carlson
Rick Matthews
Garrett D'Amore
Deny -
Abstain -
Not Participating (NP) -
THE NEXT STEP
=============
Approved
