On Tue, Mar 27, 2007 at 11:28:53PM -0800, Gary Winiger wrote: > Without authorization can't I read all property values today, > including the ones I can't set?
Yes. > It seems to me that I should > be able to read all the property values, including the ones I > can't set that do not have a read_authorization associated with > them. You can. The behaviour of reading from property groups that don't have a string-valued read_authorization property is absolutely and completely unchanged by this case. I'm not sure how else to clarify this. Perhaps a table. +---------------------------+--------------+----------------+ | PG contains string-valued | Can read | Can read after | | read_authorization prop | values today | this case | +---------------------------+--------------+----------------+ | No | Always | Always | +---------------------------+--------------+----------------+ | Yes | Always | See 2.1.2 | +---------------------------+--------------+----------------+ In table form, the algorithm in 2.1.2 could be expressed as follows. X = Don't care. Auths: R = one or more of read_authorization's entries, V = one or more of value_authorization's entries, M = one or more of solaris.smf.modify or modify_authorization's entries. +---------------------------+------------+-------+----------+ | Property | All privs? | Auths | Can read | +---------------------------+------------+-------+----------+ | X | Yes | X | Yes | +---------------------------+------------+-------+----------+ | X | No | R | Yes | +---------------------------+------------+-------+----------+ | X | No | M | Yes | +---------------------------+------------+-------+----------+ | modify_authorization | No | V | No | +---------------------------+------------+-------+----------+ | ! modify_authorization | No | V | Yes | +---------------------------+------------+-------+----------+ This table reflects the simple rule for read access to SPGs: If you can change it, or you have one of $read_authorization, you can read it. Otherwise, you can't. > tundra.eng-gww[141]: svcprop network/ipv4-forwarding > routeadm/default-ipv4-forwarding boolean false > routeadm/value_authorization astring solaris.smf.value.routing Unless you or a subsequent manifest update add a string-valued read_authorization property to the routeadm property group, this behaviour is unchanged by this case. If such a property were to be added, having solaris.smf.value.routing would still be sufficient to read and change all properties in the group, except for (if it existed) the modify_authorization property. Again, with respect to changing values, that's the same behaviour we have today. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
