noaclfab share option [PSARC/2009/661 FastTrack timeout 12/11/2009]

[Rich Brown]

The timer has expired, the discussion has converged, and this case has
two "+1"s from the two ARC members who participated in the discussion.

Also, I had upgraded the binding to "patch" with explicit approval from
Gary and saw no objections.

Thank you all for your time and participation.  I'm marking this case
as "approved".

Rich

On 12/04/09 14:36, Rich.Brown at Sun.COM wrote:
> I'm sponsoring this fast-track on behalf of Vallish Vaidyeshwara (RPE).
> This case seeks minor binding.
> 
> 
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
>noaclfab share option
> 1.2. Name of Document Author/Supplier:
>Author:  Vallish Vaidyeshwara
> 1.3  Date of This Document:
>   04 December, 2009
> 4. Technical Description
> 
> When a file is created on a Solaris NFS client, the client requests the
> "default ACL" on the directory in order to determine if the umask
> should be applied or not (See: vn_createat() --> VOP_GETSECATTR()).
> 
> Previous to the integration of ZFS, we only supported Posix Draft ACLs
> on the local file system (UFS).
> 
> Any time the NFSv2/v3/v4 client creates a file, it also requests the
> ACL from the NFS server.  If the underlying file system on the Solaris
> NFS server doesn't support Posix-Draft style ACLs, then the server
> simply "fabricates" an ACL based on the mode of the file.
> 
> Once ZFS was integrated, Solaris began supporting two distinct,
> incompatible ACL formats on the local filesystems:  Posix Draft ACLs
> (on UFS) and NFSv4-style ACLs (on ZFS).  Note that:
> 
> - ZFS supports NFSv4-style ACLs but does not support POSIX-Draft ACLs.
> - UFS supports POSIX-Draft ACLs but does not support NFSv4-style ACLs.
> - NFSv2/v3 supports POSIX-Draft ACLs but not NFSv4-style ACLs.
> 
> Since the Solaris NFSv2/v3 server cannot support the NFSv4-style ACL
> format that ZFS uses, it fabricates a Posix Draft ACL and passes it
> back to the v2/v3 client.  In other words, if all of the following are
> true:
> 
> - An ACL is requested by an NFS v2/v3 client
> - The underlying file system on the server is ZFS
> - An (NFSv4-style) ACL already exists on the file
> 
> Then the server will *still* fabricate a Posix-Draft ACL.  This causes
> the following problems as described by CR 6894228 (nfs v3/v2 should not
> fabricate ACLs).
> 
> - The fabricated (Posix Draft) ACL may be very different from the
>   legitimate (NFSv4-style) ACL that exists on the server.  Note that
>   the fabricated ACL it is based solely on the mode of the file which
>   can't represent all the information in the legitimate ACL.
> 
> - The user could retrieve the fabricated ACL on the client and attempt
>   to perform some operation only to be denied when the "real" ACL is
>   evaluated on the server.
> 
> Proposed Solution:
> --
> 
> This case proposes a new NFS share option "noaclfab" to indicate that a
> fabricated ACL should NOT be generated by the NFS server for this share
> point.  The "noaclfab" option is per share/export and the default
> behavior is to continue fabricating ACLs on NFS servers where
> underlying filesystems don't support Posix Draft ACLs.  With this
> approach, there is no risk of incompatibility with existing NFS
> clients.
> 
> Steps to enable the fix:
> 
> 
> Filesystem has to be shared using "noaclfab" option. This is a per
> share/export option and following example illustrates usage of
> "noaclfab" option:
> 
> On server:
> 
> bash-3.2# sharemgr show -vp
> default nfs=()
> zfs
> bash-3.2# sharemgr add-share -s /tank -d "noaclfab testing" default
> bash-3.2# sharemgr set -P nfs -p anon=0 -p noaclfab=true default
> bash-3.2# sharemgr show -vp
> default nfs=(anon="0" noaclfab="true")
>  /tank "noaclfab testing"
> zfs
> 
> 
> On client:
> 
> # mount -F nfs -o vers=3 nfs-server:/tank /mnt
> # getfacl /mnt/zfs-file
> /mnt/zfs-file: Operation not supported on transport endpoint
> 
> 
> Alternative solution considered:
> 
> 
> The original motivation to fabricate ACLs on the NFSv2/v3 server was
> failure of vn_createat() on the client side.  This has now been fixed
> in Nevada, OpenSolaris, and Solaris 10 code.
> 
> http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/vnode.c#1349
> 
> The team considered patching this in Solaris 9 and and lower releases.
> It is now very risky to make NFSv2/v3 servers to error out and return
> ENOSYS to clients executing VOP_GETSECATTR OTW calls.  We will have
> older releases of Solaris clients fail if Server uses ZFS as underlying
> file system.  Moreover, there might be other vendors of NFS clients who
> are now relying on this behavior of our NFS server.  Hence the safest
> approach of making this a share option.
> 
> Man page changes:
> -
> 
> "noaclfab" option needs to be documented in sharemg

noaclfab share option [PSARC/2009/661 FastTrack timeout 12/11/2009]

[Rich Brown]

Originally, I asked for "minor" binding since there was no current plan to
do a backport.  Given Gary's suggestion and since the possibility exists
that a customer may need this backported, I'd like to change the binding
to: micro/patch.

Please let me know if anyone has an issue with that change.

Thanks!

Rich

On 12/08/09 01:36, Vallish Vaidyeshwara wrote:
> Gary Winiger wrote:
>>> I'm sponsoring this fast-track on behalf of Vallish Vaidyeshwara (RPE).
>>> This case seeks minor binding.
>>> 
>>
>> Is this really only needed in Solaris Next?  It seems OK to me
>> for a Patch binding if needed.
>> +1 for either binding.
>>
>> Gary..
>>   
> Hi Gary,
> 
> This bug is an Amber Road requirement and I intent to make these changes 
> only in nevada.
> If required in future, I will backport these changes to lower releases.
> 
> Thanks.
> -Vallish

NFS Referrals [PSARC/2009/502 FastTrack timeout 09/25/2009]

[Rich Brown]

This case was approved at today's PSARC meeting.

I've put an updated man page in the case directory.

Thank you for your time and help,

Rich

NFS Referrals [PSARC/2009/502 FastTrack timeout 09/25/2009]

[Rich Brown]

On 09/23/09 10:56, Rick Matthews wrote:
> Nit: The submitted man page had "addR", "removeR" and "lookupR".
> I'm assuming the "R" is a typo.

Yes, I thought I responded to this already but I realize it was
from an off-list comment.  This will be corrected in the final version.

> 
> Should there be a reference to the privilege required for nfsref
> in the man page?

Yes, it will be added in the final version.

> 
> +1
> 

Thanks,

Rich

NFS Referrals [PSARC/2009/502 FastTrack timeout 09/25/2009]

[Rich Brown]

I forgot to include the man page for the proposed nfsref(1M) command
when I submitted this case on Friday afternoon.

This command, as proposed, is straightforward and is already described
in the text of the fast-track.  I've put a copy of the man page in the
case directory for completeness and have attached a copy to this note.

Once this case closes, I'll have the team up the the man page and add
it to the case directory.

My apologies for this oversight,

Rich
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: nfsref.1M.txt
URL: 

Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009]

[Rich Brown]

This case was approved at today's PSARC meeting.

I put an updated "final_spec.txt" in the case directory
which corrects a typo that Mahesh found.

On behalf of the team, thank you for your time and assistance
on this case.

Rich

Copy Reduction Interfaces [PSARC/2009/478 FastTrack timeout 09/16/2009]

[Rich Brown]

On 09/09/09 17:08, Garrett D'Amore wrote:
> I've not had time to go over all this yet, but do we really believe this 
> kind of change is fast track appropriate?  I have a feeling that this is 
> a significant enough core change with implications for a variety of 
> project teams, that maybe this one ought to be a full case.  I'd be a  
> bit uncomfortable allowing this one to just time out with a single +1, 
> which is the normal rule for fast tracks.
> 
> Am I alone in this particular concern?
> 
> Are there any implications for unbundled 3rd party filesystems?
> 
>- Garrett
> 

Garrett,

Perhaps this will help.

As the sponsor, I asked myself the same question.  This seemed similar
in scope to another fast-track:  PSARC/2007/315 (Extensible Attribute
Interfaces).  One could argue that this proposal is smaller in scope
and impact since there are no user level interfaces involved.

Here's what I considered during my review of the project (which might
help make the proposal a bit more digestible):


- The proposal extends the uio_t structure in a way that includes
   (and cleans up) the existing uioa_t (asynchronous uio) structure
   and adds a "zero copy" feature.  With all due respect to the original
   implementors of uioa_t, this proposal seemed like a cleaner, more
   flexible solution to extending the functionality of the uio_t structure.

   This is roughly equivalent to the way that the vattr_t structure was
   extended with the xvattr_t structure in PSARC/2007/315.

- This does not change the way that the existing VOP_READ/VOP_WRITE
   implementations work the same way that the addition of xvattr_t
   didn't change the way existing VOP_GETATTR/VOP_SETATTR implementations.

   Only those file systems that explicitly choose to participate
   in the extensions need to change their VOP_READ and VOP_WRITE
   implementations to handle the xuio_t structure.  The current use
   of the uio_t structure will still work.

- Also, only those file systems that explicitly choose to participate
   in the zero-copy feature need to implement VOP_REQZCBUF and
   VOP_RETZCBUF.  For those file systems that do not implement these
   interfaces, they will automatically default to fs_nosys() without
   any effort by the file system implementor thanks to the vnode/vfs
   operation registration mechanism (introduced in PSARC/2001/679).

Just to be clear, unbundled (Sun and 3rd party) file systems won't
notice any difference.

 Rich

nfs4_fid() [PSARC/2009/468 FastTrack timeout 09/04/2009]

[Rich Brown]

This case was approved in today's PSARC meeting.

Rich

VSD locking update [PSARC/2009/343 FastTrack timeout 06/12/2009]

[Rich Brown]

We have three positive acknowledgements and no dissenters.

The timer expires today so I'm marking this as approved.

The team thanks the members for their time on this.

Rich.

P.S.

The mail file in the case directory doesn't appear to contain
today's discussions.  (The permissions and ownership look
consistent with the mail files in other case directories.)

I have copies of the mail thread in case anyone wishes to
review them.

VSD locking update [PSARC/2009/343 FastTrack timeout 06/12/2009]

[Rich Brown]

My mistake...

I was just informed by another party that I need an acknowlegement from
at least one PSARC member.  (Somehow, I missed that change in policy and
I didn't see it documented.)

I've marked the case as "waiting fasttrack".

My apologies for this error.

Rich

On 06/12/09 15:45, James Carlson wrote:
> Rich Brown writes:
>> The timer expires today and there have been no comments.
>>
>> I'm marking this as approved.
> 
> Did anyone actually read this?
> 
> The procedure we're currently running under requires that someone
> other than the submitter or sponsor has read the proposal and ok'd
> it.  That's what all of the "+1s" are about.  Did that happen with
> this case and I just missed it?
> 

VSD locking update [PSARC/2009/343 FastTrack timeout 06/12/2009]

[Rich Brown]

The timer expires today and there have been no comments.

I'm marking this as approved.

CIFS Client Commands Update [PSARC/2009/226 Self Review]

[Rich Brown]

I mistyped Gordon's address.  This corrects my mistake.

Rich

On 04/07/09 21:03, Rich.Brown at Sun.COM wrote:
> I'm sponsoring the following for Gordon Ross.  This is an update to an
> approved case.
> 
> I believe this change qualifies for self-review and I've marked it
> Approved Automatic.  If anyone disagrees, please let me know and I'll
> promote this to a fast-track.
> 
> The requested binding is PATCH which matches the binding approved for
> the original case.
> 
> 
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
>CIFS Client Commands Update
> 1.2. Name of Document Author/Supplier:
>Author:  Gordon Ross
> 1.3  Date of This Document:
>   07 April, 2009
> 4. Technical Description
> 
>  PSARC 2005/695 "CIFS Client on Solaris" (approved on 13 Sept 2007)
>  introduced a new filesystem type: smbfs.  Since then the project team
>  realized that several smbfs-specific commands were not included in the
>  original case: dfshare_smbfs, share_smbfs, and unshare_smbfs.
> 
>  The lack of an smbfs-specific dfshares program causes the dfshares(1m)
>  command to exit with a failure code which causes regression tests to
>  fail. (See CR 6670499 for details.)  The smbfs-specific programs share
>  and unshare are being included for completeness and conformity with
>  autofs, cachefs, etc.
> 
>  This case corrects that oversight and adds the following commands:
> 
>   /usr/lib/fs/smbfs/dfshares
> 
>   dfshares_smbfs simply returns an exit code of 0
> 
>   /usr/lib/fs/smbfs/share
> 
>   share_smbfs prints "smbfs share is not supported"
>   and returns an exit code of 1
> 
>   /usr/lib/fs/smbfs/unshare
> 
>   unshare_smbfs prints "smbfs unshare is not supported"
>   and returns an exit code of 1
> 
>  Just as there are no share_{fstype}.1m, unshare_{fstype}.1m, and
>  dfshares_{fstype}.1m manual pages for autofs and cachefs, there are
>  also no corresponding manual pages needed for smbfs.
> 
> 6. Resources and Schedule
> 6.4. Steering Committee requested information
>   6.4.1. Consolidation C-team Name:
>   ON
> 6.5. ARC review type: Automatic
> 6.6. ARC Exposure: open
> 
> 

umountall -Z [PSARC/2008/765 FastTrack timeout 12/18/2008]

[Rich Brown]

This case was approved at today's PSARC meeting.
I've updated the IAM file to reflect the approval.

Thanks all,

Rich



On 12/11/08 16:24, Rich.Brown at Sun.COM wrote:
> I'm sponsoring this case for Pavel Filipensky to add the '-Z' option to
> umountall(1M).  This case times out on 12/18/2008.
> 
> Micro/patch binding is requested for this case.
> 
> 
> Template Version: @(#)sac_nextcase %I% %G% SMI
> This information is Copyright 2008 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
>umountall -Z
> 1.2. Name of Document Author/Supplier:
>Author:  Pavel Filipensky
> 1.3  Date of This Document:
>   11 December, 2008
> 4. Technical Description
> 
> This case proposes two changes:
> 
> 1) It introduces a new command line option, -Z, to umountall(1M).  When
>the umountall(1M) command is run in the global zone, this option
>applies the unmounting action(s) only to the file systems mounted in
>non-global zones.  The use of -Z option in non-global zones will
>have no effect.
> 
> 2) The default behavior of umountall(1M) is changed to limit the
>unmounting action(s) to the current zone. 
> 
> 
> Rationale for limiting the default scope to the current zone:
> 
> Currently, running umountall(1M) in the global zone unmounts file
> systems from the global zone and from non-global zones as well.  This
> is causing following bugs:
> 
>   6502014 NFS mounts in non-global zones are unmounted if NFS is restarted in 
> the global zone
>   6512906 Autofs mounts in non-global zones are unmounted when autofs is 
> restarted in the global zone
>   6777323 smb mounts in non-global zones are unmounted when smb/client is 
> restarted in the global zone
> 
> Limiting the default scope of umountall(1M) to the current zone will
> fix the bugs above.
> 
> Rationale for adding the new -Z option:
> 
> The -Z option will be used in the stop method of
> svc:/system/zones:default.  This will take care of the case when we try
> to stop zones and some of them fail to shut down.  It is better to try
> to unmount the filesystems mounted in them to free resources on the
> servers.
> 
> There are no side effects of using -Z option on other suboptions to
> umountall(1).  Using -Z never changes the behaviour of other
> suboptions, -Z only changes their scope.
> 
> 
> The webrev for these changes is available here:
>   http://cr.opensolaris.org/~pavelf/6779275
> 
> 
> Related CR:
> 
>   6779275 umountall(1M) -Z  ... limit unmounting action(s) to the non-global 
> zones
> 
> EXPORTED INTERFACES
> 
>   umountall(1M) optionStability Level
> 
>   -Z  Committed
> 
> DOCUMENTATION IMPACT (See 6780521)
> 
>   manpage umountall(1M) changes:
>   1. a new -Z option
>   2. change in the default behavior
> 
> 
>   Changes are as follows:
> 
>   SYNOPSIS
>mountall [-F FSType] [-l | -r] [file_system_table]
> 
>umountall [-k] [-s] [-F FSType] [-l | -r] [-n]  [-Z]   +
> 
>umountall [-k] [-s] [-h host] [-n] [-Z]+
>   [...]
>umountall causes all mounted file  systems  in  the  current  +
>zone except root, /usr, /var, /var/adm, /var/run, /proc, and  +
>/dev/fd to be unmounted. If the FSType is  specified,  moun-
>tall  and umountall limit their actions to the FSType speci-
>   [...]
>-s Do not perform the umount operation in parallel.
> 
>-Z Apply the action(s)  only  to  the  file  systems  +
>   mounted  in  non-global zones. By default, umoun-  +
>   tall unmounts only file systems  mounted  in  the  +
>   current  zone.  Has  no  effect if used in a non-  +
>   global zone.   +
> 
>   FILES
>   [...]   
> 
> 
> 6. Resources and Schedule
> 6.4. Steering Committee requested information
>   6.4.1. Consolidation C-team Name:
>   ON
> 6.5. ARC review type: FastTrack
> 6.6. ARC Exposure: open
> 

umountall -Z [PSARC/2008/765 FastTrack timeout 12/18/2008]

[Rich Brown]

On 12/12/08 06:23, Pavel Filipensky wrote:
> Hi Brian,
> 
> On 12/12/08 11:19, Brian Ruthven - Sun UK wrote:
>>
>> Is it ever likely to be useful to do "umountall -Z zonename" ?
> # zlogin zonename umountall
> is a way to do that
>> Perhaps to help release resources from a single zone, rather than 
>> having to umountall across all zones simultaneously?
>>
>> [ My thinking behind this is the recent change to lpstat where the -l 
>> flag suddenly started taking an additional parameter, and that broke 
>> all sorts of customer scripts which were used to the "lpstat -lp" 
>> command. I'd like to avoid a future incompatibility, but it depends on 
>> the expected target audience of this flag... ]
>>
>> Does this additional flag need to be added to the man page at all? 
>> Could it simply be a "private" flag? Is the -Z flag ever expected to 
>> be run by the average sysadmin on the command-line, or would it be 
>> confined to the zones stop method?
> -Z option might be interesting for experienced admins and for developers 
> - how they should get to know about the existence of that flag?
> -Z is proposed to be mentioned in 'Usage' as well:
> 
> # umountall -?
> Usage:
>umountall [-k] [-s] [-F FSType] [-l|-r] [-Z] [-n]
>umountall [-k] [-s] [-h host] [-Z] [-n]
> 
> Thanks,
> Pavel
>>
>> As long as the change to the default behaviour is noted (and frankly I 
>> would have expected umountall to operate in the current zone only 
>> anyway), and if the only place it is likely to be used is the zones 
>> stop method, I imagine the -Z could be an "undocumented" flag (cf. 
>> "savecore -m", only used in the bootup sequence).
>>
>> Thanks,
>> Brian
>>

In my opinion, adminstrative utilities with a system-wide effect, such
as umountall(1M), should have all of their options documented.  An
administrator may have a use for it or may simply want to know what
s/he just accidently did (oops!).  I don't see an advantage to make this
option private.

Unless there's a compelling reason to keep this private, then let's let
the proposal stand as a publicly documented option.

Rich

Correction in nbmand behavior [PSARC/2008/584 FastTrack timeout 09/23/2008]

[Rich Brown]

This case was approved at today's PSARC meeting.

I've updated the IAM file accordingly.

Rich

64 bit offsets for VOP_DUMP [PSARC/2008/053 FastTrack timeout 02/01/2008]

[Rich Brown]

This was approved at today's PSARC meeting.

I've marked this as closed approved.

Rich

Caller context flags [PSARC/2007/632 FastTrack timeout 11/09/2007]

[Rich Brown]

This was approved at today's PSARC meeting.
I've updated the IAM file.

Rich

Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007]

[Rich Brown]

This case was approved at today's PSARC meeting.

The team has updated the spec and have provided diff output
for the stat(2) and fsattr(5) man pages.  I've deposited
the following files in the case directory:

spec.txt - Updated final spec

stat2_diffs.txt - diff output for stat(2)

fsattr5_diffs.txt - diff output for fsattr(5)

I also renamed the IAM file (IAM.Add__AT_TRIGGER_to_fstatat)
and changed the project name (Add _AT_TRIGGER to fstatat).
I sent mail to John Plocher with the new IAM information.

Thanks for the help on this,

Rich

Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007]

[Rich Brown]

After discussing the security issues with the concerned PSARC members, the team
has decided to modify the proposed solution.  The proposal no longer includes
adding S_IFTRIGGER as a bit in st_mode and S_ISTRIGGER() as a macro.

The team agrees with PSARC's advice and proposes to add the AT_TRIGGER bit to
the flag parameter of fstatat().

The first attachment (spec_update.txt) is the updated spec with diff-marks.  The
second attachment (stat2_diffs.txt) is the diff of the update to the stat(2) man
page.

I'm extending the timer to this Friday, 10/12, to allow time for any additional
questions to settle.

The team will be available for questions at the PSARC meeting.

  Rich

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: spec_update.txt
URL: 

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: stat2_diffs.txt
URL: 

Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007]

[Rich Brown]

Rich Brown wrote:
> 
> The team just met with Don Cragun to discuss the concerns.  We've all
> agreed on how to proceed.  Notes coming out shortly and I'll summarize
> on the alias.
> 
> Rich


- Don and the team agreed to the following:

   * The case would continue, but the commitment level would be changed
 to "Consolidation Private" since the only known use of this is for
 the find/nftw(3c) problem.  This would also eliminate the proposed
 change to the stat(2) man page.

   * Rich will submit a CR describing the existing security holes.  Don,
 Jim Carlson, and the team will be on the Interest List.

 (I'm currently investigating what security holes still exist and
  will submit the CR with my findings.)

   * If the team find an additional use for S_IFTRIGGER, then the team
 will submit a fast-track to upgrade the commitment level.

   * When the security issues are fixed (either by Jim Carlson's fstatat()
 suggestion or some other solution), then obsolete/remove the S_IFTRIGGER
 bit (assuming the team hasn't upgraded the commitment level).

Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007]

[Rich Brown]

James Carlson wrote:
> John Plocher writes:
>> James Carlson wrote:
>>> How's that?
>> The difference I see is that in the original case, only autofs
>> triggered mount points were handled by this code path; in the
>> new code allows anything that sets S_TRIGGER will, uhm, trigger
>> this code path.
>>
>> As long as only autofs does it, things are identical.  If anything
>> else does...
>>
>> At least, that's how I parsed it.
> 
> That's what appears to me to make it identical.
> 
> If the project team is actually making _more_ file systems set
> S_TRIGGER, then I agree that the bug has been crowbared open a bit,
> and that might well be enough to push me into the "opposed" camp.
> 

The team just met with Don Cragun to discuss the concerns.  We've all
agreed on how to proceed.  Notes coming out shortly and I'll summarize
on the alias.

Rich

Add S_IFTRIGGER to st_mode [PSARC/2007/563 FastTrack timeout 10/04/2007]

[Rich Brown]

At the PSARC meeting today the timer was extended to Wednesday, 10/10/2007.

I've updated the IAM file.

Rich

Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007]

[Rich Brown]

Gary Winiger wrote:
>> Based on some of the questions we've gotten and the discussions we've
>> had, the project team has realized that there is some confusion that we
>> need to clear up.  Our apologies for not realizing this sooner and for
>> not explaining this well enough in the original spec.
> 
>   Thanks.  I believe this converges things for me.
> 
>> Point taken.  We'll update the spec to be more precise.
> 
>   At least for me, I'd like to see the update before final
>   approval.  
> 
> Gary..

Gary,

See the attached files:

   spec_diffs.txt - diff output against the original spec

   sysattrs-spec-3.txt - updated spec

The team will be attending the PSARC meeting today.

Rich

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: spec_diffs.txt
URL: 

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: sysattrs-spec-3.txt
URL: 

Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007]

[Rich Brown]

Gary Winiger wrote:
>> Based on some of the questions we've gotten and the discussions we've
>> had, the project team has realized that there is some confusion that we
>> need to clear up.  Our apologies for not realizing this sooner and for
>> not explaining this well enough in the original spec.
> 
>   Thanks.  I believe this converges things for me.
> 
>> Point taken.  We'll update the spec to be more precise.
> 
>   At least for me, I'd like to see the update before final
>   approval.  
> 
> Gary..


Hi Gary,

I expect that the updated spec will be available between 8AM and 9AM
Pacific.

We'll include the diffs from the original spec to expedite matters.

Thanks,

Rich

2007/315 [Extensible Attribute Interfaces]

[Rich Brown]

Glenn Skinner wrote:
> Date: Wed, 06 Jun 2007 12:02:44 -0500
> From: Rich Brown 
> Subject: Re: 2007/315 [Extensible Attribute Interfaces]
> 
> Glenn Skinner wrote:
> > 
> > Suppose someone desires to add a new "system" attribute.  By what
> > criteria can we (the ARC) judge whether that attribute qualifies
> > as being a "system" attribute?  That is, what constitutes
> > "systemness" in an attribute?
> 
> I believe that if an operating system module needs to use the value
> of an attribute to make a decision, then that attribute is
> considered a system attribute.
> 
> Let's probe this characterization a bit.
> 
> At first glance, this just seems to move the question to what
> constitutes an operating system module.  Does this mean somethng that's
> part of the kernel's address space?  Or (as was suggested during
> today's PSARC meeting) does this mean something that's part of the
> trusted computing base?
> 
> Consider, for example, a third party HSM that wants to maintain an
> attribute that records an offset beyond which the file's data is staged
> out to tertiary storage.  Is this a system attribute?  Depending on how
> the HSM is implemented it may or may not be interpreted by code
> residing in the kernel address space.  The HSM will almost certainly
> require some level of elevated privilege to operate successfully.  Does
> that push it into the trusted computing base?  If we decide the
> attribute does qualify as a system attribute, would or should the HSM
> vendor need to get ARC approval for the attribute name and to have it
> live alongside the other system attributes?
> 
> Questions like these make me uneasy about introducing a potentially
> open ended set of "system" attributes.  The ones proposed as part of
> this case all seem (more or less) reasonable.  But the case also
> outlines a scheme for extensibility.  I would like the bounds for what
> qualifies for inclusion to be as clear as possible.  (And for extra
> credit, I would like that hypothetical third party HSM vendor to be
> able to deliver product without having to visit PSARC.)
> 
>   -- Glenn
> 

In determining if an attribute should be considered a system attribute
or should simply follow the current (opaque) extended attribute model,
there will be black-and-white cases and there will be gray areas.

For those gray areas, the project team's advice to the ARC is to
challenge any proposal for new system attributes with the following
questions:

- Do operations on the file itself (e.g., open, read, write, close,
   unlink) cause the file system to modify the attribute?  If so, then
   it's a system attribute.

   For example, writing to the file would cause the file system to set
   the AV_MODIFIED attribute.

- Does the file system that implements the attribute make decisions based
   on the value of that attribute?  If so, then it's a system attribute.

   For example, the file system will not allow a caller to write to
   anywhere but at the end of a file if the file has the APPENDONLY
   attribute set.

- Does the kernel need to protect the format and/or value of the
   attribute for the value to be useful to consumers other than the one
   that set the value?  If so, then it may be a system attribute.

   For example, CREATETIME must be in a time format (timestruc_t).

- Is there a precedent in another operating system for the attribute
   being a system attribute?

   For example, on FreeBSD the NODUMP attribute is stored as a bit in
   the UFS inode and can be retrieved with stat(2) by ufsdump.

- If all else fails, what justification does the project team have for
   proposing an attribute to be a system attribute as opposed to an opaque
   attribute?

   There may be legitimate reasons for proposing that an attribute be a
   system attribute.  For example, an anti-virus facility integrated
   into Solaris might require a "scanstamp" to be stored as a system
   attribute for the following reasons:

- If the virus-scanner needed to check the scanstamp on every
  open, that means each open must do an open and read on the
  extended attribute file containing the scanstamp which would
  be a severe performance penalty.

- Storing the "scanstamp" as an extended attribute might be
  prohibitive since the file being scanned could itself be an
  extended attribute file.  Recall that extended attributes on
  extended attributes may not be supported depending on the
  implementation.  (See section 4.6 on the opinion for PSARC
  1999/209).

... and we're not going to get that extra credit unless, of course,
the hypothetical vendor agrees to using the existing (opaque) extended
attribute facility.  Changes to support new system attributes will touch
enough to justify PSARC attention.

Rich

2007/315 [Extensible Attribute Interfaces]

[Rich Brown]

At the PSARC meeting, the project team was asked to summarize
the changes in the spec since it was sent out on 30 May.  I
volunteered to provide this.  (I have not included a summary
of the discussions which resulted in no change to the spec.)

- The team agreed that the NODUMP attribute could be set
   on Solaris.  However, RFEs would need to be opened for the
   various archivers to pay attention to the attribute.

- Spencer informed the team that the SYSTEM attribute is
   also one of the NFSv4 recommended attributes (along with
   ARCHIVE and HIDDEN).

   I also found that CREATETIME (time_create) is also one of
   the recommended attributes.

   This will updated in section 4.3.1 of the spec.

- The project team has agreed to remove the PRIV_FILE_FLAG_CLEAR
   privilege and require a process to have "all" privileges in order
   to clear the attributes listed in sections 3.2, 3.4, plus NODUMP
   from section 3.3.

2007/315 [Extensible Attribute Interfaces]

[Rich Brown]

Glenn Skinner wrote:
> Date: Wed, 30 May 2007 13:19:19 -0600 (MDT)
> From: Timothy Haley - Sun Microsystem 
> Subject: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack
>   timeout 06/06/2007]
> 
> ...
> 2.0 OVERVIEW
> 
>   The Solaris CIFS project requires file system support for a
>   number of "system" and opaque file attributes.
> 
> Suppose someone desires to add a new "system" attribute.  By what
> criteria can we (the ARC) judge whether that attribute qualifies as
> being a "system" attribute?  That is, what constitutes "systemness" in
> an attribute?
> 
>   -- Glenn
> 

I believe that if an operating system module needs to use the value of an 
attribute
to make a decision, then that attribute is considered a system attribute.

Rich

Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007]

[Rich Brown]

I just got off the phone with Nico.  Turns out we're in violent agreement.

I thought he was talking about exposing the system extended attribute files
(SUNWattr_rw, SUNWattr_ro).  But Nico was talking about the individual
attributes (CREATETIME, SYSTEM, HIDDEN, etc., etc.).

We've agreed that a future project should add the new attributes to
the Solaris client and server as the NFSv4 protocol allows.  This is
briefly described in section 4.3.1 of the spec for this case.

We also agree that the work in described in sectin 4.3.1 is outside
the scope of this project.

Sorry for the confusion.  Thanks.

Rich


Nicolas.Williams at Sun.COM wrote:
> Rich Brown wrote:
>> The system attribute files (SUNWattr_rw, SUNWattr_ro) are not intended
>> to be used as NFS named attributes directly.  The format of these files
>> are nvpairs of the system attributes.  I wouldn't expect all NFS clients
>> and servers to recognize Solaris' nvpair format.
> 
> I would expect a future project to make these attributes visible through 
> NFSv4 to make each attribute visible as a separate named attribute, not 
> all of them in one file with nvlist format.  But then, perhaps we'd 
> pursue different extensions to NFSv4 for this anyways.
> 
>> Regarding the registration of named attributes, RFC3530 states:
>> "the intent is to promote interoperability where common interest exists".
> 
> But surely also there is a namespace collision avoidance rationale.  In 
> the case of applications there is no problem since presumably two (or 
> more) different apps using conflicting attribute names wouldn't share 
> the same files.  While in the case of the operating system as the 
> application we could expect every file to have these attributes, so the 
> namespace conflict avoidance issue matters.
> 
> I suspect that the NFSv4 WG only intended for imlementors of clients and 
> servers that rely on special named attributes to register them, whereas 
> application developers wouldn't have to.  Whatever.  The WG chose a 
> method too difficult to use, so we shan't (and if anyone insisted I'd 
> suggest simply not allowing these SUNW attrs to be visible via NFSv4).
> 
>> But the team is not claiming interoperability with these two attribute
>> files.  Interoperability would happen with the attributes stored WITHIN
>> these attribute files.
> 
> No, the team isn't claiming interop, but folks outside Sun might like to 
> support these attributes -- I believe that's what the RFC wants us to 
> facilitate.
> 
>> Registering these attribute files with the IANA means that the project
>> team would have to publish an informational RFC to state the name of the
>> attributes (SUNWattr_rw and SUNWattr_ro) then describe the syntax and
>> semantics of the named attribute contents.  Any new attributes added
>> to these files would require project teams to submit updates to the RFC.
>> As Nico said, this is "a very heavy-weight procedure".
>>
>> Given that, I don't see the value for Sun in registering the system
>> attribute files as named attributes for NFS through the IANA.
>> I see it as a high cost for no gain.  Not that we think that anyone
>> is going to use SUNWattr_* (or whatever we decide on) but the IANA
>> registration doesn't even claim to prevent name collisions.
> 
> Really?  No NFSv4 client implementor would see any value in 
> understanding and supporting the use of these attributes?  I somehow 
> doubt that.
> 
> Nico

Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007]

[Rich Brown]

Nicolas Williams wrote:
> On Thu, May 31, 2007 at 10:45:04AM -1000, Joseph Kowalski wrote:
>> Garrett D'Amore wrote:
>>> Also, I find the reverse DNS naming scheme dissatisfying ... it makes 
>>> everything quite a bit longer than it really needs to be to provide 
>>> the separation of the namespace that is desired.  It also ignores the 
>>> bit that not everyone who wants to participate will have a DNS domain 
>>> name, or that the domainname will not change over time.  (E.g. due to 
>>> mergers, buyouts,  insolvency, or rebranding.)
>> True enough, but it is better than Stock Symbols (How much would a 
>> domain name cost me?  How much would a stock symbol cost me?)  More 
>> importantly, its the fairly widely accepted convention these days.
>>
>> My only point is that Solaris/OpenSolaris/Sun/whatever is special.  
>> Somebody would have to be from another planet to step on SUNW.
>>
>> A discussion as to what the suggested form for others should be is a 
>> separate discussion - not this case.
> 
> IF RFC3530 had provided a light-weight registration procedure for the
> named attribute namespace, and IF we could treat that as authoritative
> for Solaris' extended attributes namespace, THEN there would be NO NEED
> for any prefix, though we might pick a very generic prefix, like
> "system." to help avoid conflicts with apps that use unregistered named
> attributes.
> 
> BUT, NEITHER does RFC3530 provide such a light-weight registration
> procedure, NOR is it obvious that we could use its named attribute
> registry as authoritative for Solaris' extended attrs namespace: though
> fsattr(5) is quite unclear on that point, as it does reference RFC3530
> and says that NFSv4 named attrs and Solaris extended attrs are
> "equivalent," but then misrepresents what RFC3530 says about this
> namespace.
> 
> (RFC3530 allows one to use any named attr name one wants but encourages
> folks to follow a very heavy-weight procedure for registering them!
> Guess how many app developers will bother to register their named attr
> names?  What is the point of such a registry if noone will ever use it?)
> 
> I think we do need an authoritative registry for this namespace, and its
> registration procedures ought to be exceedingly light-weight, else noone
> will register their named attr names.  IANA is as good a registrar as
> any.  I think advice to the IETF NFSv4 WG to loosen the registration
> procedures is in order.
> 
> Advice to the i-team to register these attributes, even though the
> current process is painful, seems in order as well.
> 
> *sigh*
> 
> Nico

The system attribute files (SUNWattr_rw, SUNWattr_ro) are not intended
to be used as NFS named attributes directly.  The format of these files
are nvpairs of the system attributes.  I wouldn't expect all NFS clients
and servers to recognize Solaris' nvpair format.

In terms of NFS support for the system attributes contained in these files,
see section 4.1 of the spec:

  4.3.1 NFSv4 Support for Optional Attributes (Potential Future Work)

   The NFSv4 protocol has an attribute model that supports extensions.
   In fact, two of the new attributes (ARCHIVE and HIDDEN) are part of
   the "recommended" list of attributes for a client and server
   implementation.  The Solaris NFSv4 client and server could be
   modified to support the new, optional attributes as specified by
   the protocol.

   This work is not currently funded.

Note that SYSTEM needs to be added to the list.  (Thanks Spencer!)


Regarding the registration of named attributes, RFC3530 states:
"the intent is to promote interoperability where common interest exists".

But the team is not claiming interoperability with these two attribute
files.  Interoperability would happen with the attributes stored WITHIN
these attribute files.

Registering these attribute files with the IANA means that the project
team would have to publish an informational RFC to state the name of the
attributes (SUNWattr_rw and SUNWattr_ro) then describe the syntax and
semantics of the named attribute contents.  Any new attributes added
to these files would require project teams to submit updates to the RFC.
As Nico said, this is "a very heavy-weight procedure".

Given that, I don't see the value for Sun in registering the system
attribute files as named attributes for NFS through the IANA.
I see it as a high cost for no gain.  Not that we think that anyone
is going to use SUNWattr_* (or whatever we decide on) but the IANA
registration doesn't even claim to prevent name collisions.

Rich

Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007]

[Rich Brown]

Spencer Shepler wrote:
...
>> 4.3.1 NFSv4 Support for Optional Attributes (Potential Future Work)
>>
>>   The NFSv4 protocol has an attribute model that supports extensions.
>>   In fact, two of the new attributes (ARCHIVE and HIDDEN) are part of
>>   the "recommended" list of attributes for a client and server
> 
> and SYSTEM
> 
>>   implementation.  The Solaris NFSv4 client and server could be
>>   modified to support the new, optional attributes as specified by
>>   the protocol.
> 

I thought I missed one, but my eyes must have glazed over while looking
through the spec.  Good catch, Spencer.  We'll add that.

Rich