Gary Winiger wrote:
> I'm slowly getting caught up here.  From my first reading,
> I have two nits:  The spec says micro binding.  CIFS server I suspect
>       in minor.  I don't believe there is any micro release planned.
>       I can see this project being useful before S11, perhaps a
>       patch binding is appropriate.
> 

Oops... That's a typo.  The team requests MINOR binding.

>       The man page says "Evolving" that should be "Committed".
> 

This will be fixed

> Now some real questions:  Perhaps there's overlap with Glenn's line.
>       Perhaps this has been answered.  As I asked in the meeting today,
>       a summary of the spec changes would.  How is the Sun/Solaris distro
>       name space managed?  I can see once zfs is bootable wanting to add
>       various "system" attributes.  How will collisions be avoided with
>       other possible distros?
>       

Rich sent a summary earlier today.

New system attributes will be added in the xvattr_t/xoptattr_t data
structures and stored in the file system as appropriate.  These will be
exposed as nvpairs in the SUNWattr_rw/SUNWattr_ro views as appropriate
so there's no collision in the extended attribute namespace.

As for the names of the attributes themselves
(CREATETIME, READONLY, etc.) see section 4.4  Managing Change in the 
Attribute Space.


>       Can each attribute have a separate policy?  For example, I may
>       wish to associate privileges with executables or file signatures
>       with each system data file.  To view the privileges or signature
>       may not require any policy (beyond the default).  However, to
>       modify should likely require some special policy.
> 

A separate policy could be added for an individual attribute as needed
but that isn't necessary for the proposed attributes.  As discussed in
a previous email, any work with signed files would be a future project.
The current policies are defined in sections 3.1, 3.2 and 3.3.

>       Is there some thought that "system" attributes are ones that
>       require some policy either to view or modify?

Putting that policy into place wouldn't be difficult to do but none of
the proposed attributes have that requirement.

>       Perhaps defining what does NOT constitute a "system" attribute
>       would be helpful.  One might say that other distros could use
>       the XXX_ro / XXX_rw name space.
> 

Please see the previous response to Glenn's question about determining
if an attribute is a system attribute.

> I'm planning to go back over the materials and discussion again.
> 
> Thankx,
> Gary..


Reply via email to