> I'm planning to file this case with PSARC next week. I'll also follow
Thanks for pre-ARCing. We like to encourgage ARC early;
ARC often ;-)
> 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?
> 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?
> 2.4. svccfg(1M) changes
>
> 2.4.1. export changes, introduction of exportall
>
> 'svccfg export' is modified to export the values of properties in
> SPGs as if they had no values, regardless of whether the user performing
> the operation has the required authorization. This prevents accidental
> exposure of sensitive data in XML documents used for interchange
> purposes.
I believe this needs guidance in the SMF policy. If you use
read_authorization properties, the manifest should not initialize
the default value to anything sensitive.
> 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?
> 3. Manual page changes
>
> Diffs to relevant manual pages are included in the case materials.
> Modified
> man pages are:
Additionally I believe the policy needs to be updated.
It should outline the form. VIZ.
solaris.smf.read.cioppino
And as noted above guide against putting sensitive values
in the manifests as they are (at least today) publically readable.
> Well-known property 'read_authorization' Committed
>
> No case explicitly defines the commitment level of the well-known
> properties 'modify_authorization' and 'value_authorization'[3]. Given
Well if the case owner (some gww guy) had his act together, and
the project team had ever actually done the required spec updates,
this may have been caught.
> their semantics, their presence in smf_security(5), and the probable
> intent that they be introduced as Evolving, this case also clarifies
Evolving it would have been.
> 4.2. Interfaces Imported
How does the repository protect sensitive values from view?
What requirements does this place on remote repositories?
Have the NSS2/Sparks folk been included in any new remote
repository requirement?
Gary..
