On Wed, Aug 27, 2008 at 03:15:31PM -0700, Scott Rotondo wrote: > So apparently there is more divided opinion on this issue than I > thought. Who would have guessed? ;-) > > I think that individual privilege and authorization names should be the > stable interfaces presented to administrators rather than the names of > RBAC profiles that contain them. My reasons for this view include the > following: > > [...] > > 2. There is no intent to prevent overlap between RBAC profiles. The same > authorization, for example, may be granted by multiple profiles included > in Solaris, as well as additional ones defined by the user. In such an > environment, there is no obvious rationale for selecting which profile > to specify on a man page like this one. > > [...]
IMO profile names and semantics are more likely to be stable than authorization names and their semantics. That is mostly because authorizations are very specific and therefore tend to expose some implementation details (e.g., the 'smf' part of most authoritzations used by SMF services), whereas profiles are typically, and by necessity broader in scope than authorizations. That customers can create new profiles that overlap with Sun-provided profiles is actually a good thing: it allows customers to deal with backwards incompatible changes to authorizations (e.g., removals of authorizations) by updating just the affected customer-maintained profiles, as opposed to the affected user_attr(4) entries. The former is easier to do than the latter. The change that's really interesting in this case is that coreadm will no longer require use of pfexec (or profile shell, or root shell) to execute it with privilege, but using pfexec as usual will not break. The inverse would not have been a backward compatible change. IMO we should encourage developers to design suitable profiles and make their interface stability match that of the most stable project component related to that profile, and we should allow authorizations to be less stable. E.g., "profiles should be Committed and authorizations may be Uncommitted." And we should explicitly document "requires privilege"->"requires authorization" changes as backward compatible while the reverse is not [until a project comes along that makes explicit use of pfexec unnecessary]. Nico --
