On Tue, Mar 20, 2007 at 09:52:53PM -0700, David Bustos wrote:
> "The read_authorization property...": I presume you're not planning on
> stopping anyone from creating read_authorization properties in
> non-application property groups. Perhaps it would be better to talk
> about how that property will be interpreted in those property
> groups.
I've adjusted this language to make it clear that this property will
be interpreted as described for all group types except the three noted
(framework, dependency, method).
> "It is defined...": Similarly, I presume you're not planning on
> stopping anyone from creating read_authorization properties with
> types other than "astring". You should probably say that such
> properties will be ignored.
Nothing here will prevent anyone from creating anything. I'll note
explicitly that non-astring read_authorization properties will be
ignored.
> "Each string value...": Similarly, defining the values to be RBAC
> authorizations won't make them authorizations. You should probably
> say that they will be interpreted as RBAC authorizations.
Ok.
> - Is it too pedantic to worry about applications or users who are
> already using properties named "read_authorization"?
I think so. I'm not aware of any service using this property, and the
similarity of its name to existing reserved names should have
discouraged anyone from doing so. It would have been better to have
reserved a part of the property namespace, but this was not done.
> 2.1.2. svc.configd(1M) RPC changes
>
> "If the requesting client would be permitted...": I presume that "to
> modify" includes value modification, as in the value_authorization
> sense?
Yes. It means exactly what it says: if you can change the value, you
can read it. It does not matter how you obtain the right to change
it.
> - Shouldn't the read_authorization property itself be world-readable
> so that software can determine whether permission was denied becasue
> of it? Similarly for action_, modify_, and value_authorization.
No. Knowledge of the authorization required to perform an action is
potentially valuable information. Attacking a system is not an
adventure game; we don't say "you need the blue key to open this
door" to encourage the player to go find the right one.
(I'll note that the existing implementation exposes the values of the
authorization properties. Correcting this is outside the scope of
this case, which provides only for per-group granularity.)
> - Will read_authorization's of service property groups be inherited by
> instance property groups?
Yes.
> - When the client is reading from a snapshot, will the snapshot's
> read_authorization be used, or the instance's current value?
The snapshot. The authorization and the sensitive information
required to obtain it go together.
> 2.3. svcprop(1) changes
>
> "the present behaviour...": I think you should clarify this, since
> svcprop displays different things for a property with no values and
> a property with a single value which is the empty string.
The change I made here was at gww's recommendation. I too felt the
original language was clearer. Do either of you have suggestions for
alternate language?
> 2.4.1. export changes, introduction of export -a
>
> "'svccfg export' is modified...": Will the values of
> read_authorization also be omitted?
Yes. The effect applies to the entire property group, always.
> 4.1. Guidance
>
> - It seems that you have changed the period at the end of
> "solaris.smf.{manage, modify, value}." to a comma. I suspect that's
> incorrect, because I believe the punctuation was not for English
> syntactic reasons, but because we intend for the service author to
> use these strings as a prefix on his service-specific
> authorizations. Perhaps you should clarify this by making the
> string "solaris.smf.{manage, modify, value, read}.<token>" or some
> such.
Yes, that's an error. I'll correct it.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
