Bart, where did the original request for this finer grained user application environment policy control come from? If customers are asking, please let us know.
-Christoph Scott Rotondo wrote: > Glenn Faden wrote: >> Bart, >> >> In general I don't think that the existing RBAC implementation is the >> right architecture for implementing restrictive environments. The >> original goal was to configure administrative roles, not to confine >> ordinary users. However, I agree with your suggestion making it >> configurable whether the values of AUTHS_GRANTED and PROFS_GRANTED are >> appended to the respective lists. The keyword use_defaults may be >> misleading since all the rest of the default in policy.conf would still >> apply. >> >> A more extensible approach would be a list of which default settings to >> ignore, e.g. >> >> ignore_defaults=auths,profs >> >> however, right now I can't see any other defaults currently in >> policy.conf that should be ignored. >> >> The FMAC project, http://opensolaris.org/os/project/fmac/ , is >> specifically goaled to address the issue of restricting the individual >> applications that a user can execute, and what resources those >> applications have access to. I think that any further enhancement to >> the existing RBAC implementation should take into account how it could >> be merged with the evolving FMAC architecture. Ultimately we want to >> combine these two implementations in a compatible way so that the >> customer can benefit from both features. >> >> --Glenn >> > > I was about to reply, when I saw that Glenn already made all the points > I would have. So I'll just say +1. > > Scott >
