On Tue, Mar 27, 2007 at 03:29:00PM -0800, Gary Winiger wrote:
> > 2.1.1. Definition
> >
> > The read_authorization property may optionally be added to any
> > property group of type application (SCF_GROUP_APPLICATION). It is
> > defined to be a string-valued property with zero or more values. Each
> > string value (if any) of this property will be interpreted as the name
> > of an rbac(5) authorization defined in auth_attr(4). A
> > read_authorization property which is not string-valued will not be
> > interpreted specially.
>
> I don't understand this last sentence. I thought that the
> read_authorization property was similar to method, modify, and
> value_authorizations in that its type was string.
It is. Feedback indicated that the original expression was unclear,
that it could have been read to mean we would prevent the creation of
non-string-valued properties with these names. That is not how the
existing properties work, nor is it how we intend read_authorization
to work. To clarify this, we require that the property be
string-valued in order to be subject to the interpretation we define.
It is permitted, but not meaningful with respect to this case, to
create read_authorization properties with non-string types.
As clear as I can make it: The semantics of read_authorization with
respect to property type are identical to those of the existing
well-known properties.
> > 2.3. svcprop(1) changes
> >
> > With respect to SPGs, svcprop(1)'s behaviour is modified as follows:
> >
> > - If a property or property group was explicitly specified with -p,
> > and svc.configd(1M) denies access to the values of the specified
> > property/ies, svcprop(1) will abort and, unless the '-q' option was
> > provided, display an error message.
>
> What does abort mean in this context? Does it call abort(3C),
> or does it return an error?
It returns an error.
> > - 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 (the present behaviour is to
> > display the empty string for the value of such properties).
>
> I don't understand this last sentence. Is the present behavior
> being modified? Would string valued properties have "0" returned?
> Would string valued properties have an empty string returned?
Neither. The existing implementation has well-defined behaviour in
the face of properties with zero values (that is, the cardinality of
the set of values for the property is 0): it prints nothing - not "",
not '', not 0, but nothing at all: the zero-length string. This case
defines the behaviour in the face of insufficient permission to be
identical unless -p is specified. No existing behaviour is being
modified with respect to zero-valued properties, nor with respect to
non-sensitive property groups.
This demonstrates the existing behaviour of svcprop(1) on zero-valued
properties.
root at fallout:~ # cat /tmp/testprop
#! /bin/sh
die() {
echo $1 >&2
exit 1
}
svccfg <<EOF
select nis/client
addpg foo application
setprop foo/bar = integer: ( )
quit
EOF
(svcprop nis/client | grep foo) || die "Zero-valued props are broken!"
svccfg -s nis/client delpg foo
root at fallout:~ # /tmp/testprop
foo/bar integer
root at fallout:~ #
The type of the property does not matter; all zero-valued properties
are displayed identically.
> > smf_security(5)
>
> > value_authorization Authorizations allow changing the
> > values of any property of the property
> > - group except modify_authorization.
> > + group except modify_authorization, and
> > + the retrieval of any property values
> > + except modify_authorization from the
> > + property group if sensitive.
>
> Does this case modify the action of value_authorization with
> respect to modify_authorization? I'm not sure what it is
> saying. I can read it as saying the value_authorization
> doesn't allow the retrieval of the value of a modify_authorization
> that is present in a sensitive property group. I'm not sure
> that makes sense.
>
> The way I've read this proposal, if I can change the sensitive
> property value, I can read it. Please clarify.
Correct - if you can change it, you can read it. Having an
authorization named by value_authorization is not sufficient to change
the values of modify_authorization; therefore, for sensitive property
groups, neither is it sufficient to read those values.
--
Keith M Wesolowski "Sir, we're surrounded!"
FishWorks "Excellent; we can attack in any direction!"
