> On Mon, Mar 19, 2007 at 08:56:07AM -0800, Gary Winiger wrote:
In general my points were to have the document that goes to
ARC review updated to reflect the answers to questions I would
have raised if this had been the review.
IMO, a good fast track is one with no discussion.
> > > 2.1.1. Definition
> > >
> > > The read_authorization property may optionally be added to any
> > > property group of type application (SCF_GROUP_APPLICATION). It is
> >
> > Why should it be restricted to only application PGs at this time?
> > What's the drawback of being general?
> sensitive; I don't see a benefit that would justify the amount of
> complexity that would introduce.
Seems reasonable to expand and give the rationale.
> > > 2.3. svcprop(1) changes
> >
> > > - If no property or property group was specified, properties for
> > > which the user lacks appropriate authorization to read will be
> > > displayed as if they had zero values.
> >
> > Are string values the empty string?
>
> All properties with no values show up as the empty string; i.e.,
> So yes.
Just saying zero values is incomplete, adding empty string
> > > To provide the ability to export documents containing the values of
> > > sensitive properties, we introduce 'svccfg exportall'. This command
> > > behaves identically to 'export', except that the values of properties
> > > in
> > > SPGs are exported if the user has sufficient authorization to read
> > > them.
> > > Otherwise, the command terminates and displays an appropriate error
> > > message.
> >
> > Does it terminate at the first SPG, or will it always terminated
> > just in case there may be an SPG in the repository even if there
> > are none?
>
> It will abort only if an SPG is encountered for which the user does
> not have sufficient authorization to read its contents.
Good to say so.
> > How does the repository protect sensitive values from view?
> implementation details, though; I can provide a webrev in a couple of
> days if you want the nitty-gritty.
I was actually thinking of something much simpler. I'd not recalled
the permissions on the repository. The repository is protected
from public read access.
> > What requirements does this place on remote repositories?
>
> Since the interface between svc.configd and a remote backend is not
> to do so on the affected hosts). This change requires the same
> capability with respect to reads. The most likely future networked
> backend, LDAP, already offers this capability.
Greenline itself did lay out the intention for remotly served
repositories.
Is is really LDAP (which is a protocol), or is it the directory
server implementation(s) that provide for different access control
policies?
> > Have the NSS2/Sparks folk been included in any new remote
> > repository requirement?
>
> I don't see anything in the Sparks (nor Duckwater) materials to
> suggest that they're considering implementing networked backends for
> SMF. If I've overlooked something here, please let me know.
Right there may be nothing in the current materials. The broader
perspective is that the repository can be centrally served. NSS2
is the umbrella that would likely provide that service. Until
this case, there were no requirements to protect anything beyond
update protections. IMO, that allows a lot of flexability in the
schema -- not being a directory server (or access protocol) expert,
it seems reasonable to me to suggest a discussion with NSS2 so
they can possibly provide input that is relevant to this case.
Recall Greenline made such statements as, gww's paraphrase,
privacy of values was outside the scope, but could be done with
encryption if needed and it was incumbant on the service to provide
whatever was needed. This case changes that architecture.
Consulting with other project teams that might be affected seems
reasonable.
Gary..
