Forum OpenACS Development: Re: Best Practices for permissions, straw man

Collapse
Posted by Don Baccus on
I think one way to get a handle on what generic permissions we should define and how to define their semantics would be to survey a bunch of existing packages.  Some of them go way to far with the granularity the provide (OF tended to go that direction IMO).  Others don't.  But at least you can get a handle on what kind of access problems they were trying to solve.

Your GRANT privs currently are implemented using the single ADMIN privilege, and I personally have never run into the need for greater granularity.  I realize RDBMS security models tend  to provide an extremely granular solution but IMO these also tend to be more complex than we need - and I'd argue more complex than they generally need, too.

Tom's discussion regarding restricting actions on attributes could easily be solved within the permissions system if we made attributes objects.  I'm not suggesting we pay that implementation cost, only that Tom's solution to this problem is made necessary by a compromise in the permissions/object model.

Collapse
Posted by Tom Jackson on

I wouldn't go so far to say that my solution was necessary because of problems with the permissions/object model. Permissions apply to individual objects, or if attributes were objects, they would apply to individual attributes. Roles apply to object types. In most applications, except workflow, roles are implicitly defined by the ui. The UI gives meaning to the permissions. You can add privileges and subprivileges all day long, but that doesn't do anything about defining a role. A role exists before individual objects are created and continues to exist independent of individual objects. But when you remove an object, you have to remove permissions first.