On Wed, 2001-11-28 at 12:15, Mike Orr wrote:
> On Wed, Nov 28, 2001 at 02:12:13AM -0600, Ian Bicking wrote:
> > > - Do you ask the user object if he has permission to do X to Y, or do you
> > > ask Y if user U can do X?
> >
> > You might ask either if they have an opinion, and take the greater
> > (less?) permissive answer.
>
> If there's a single, convenient wrapper method that does all this and
> returns a boolean (or raises a security exception), OK. But I wouldn't
> want to do this min(userPerm(action), objectPerm(action)) on every
> protected object, or worse, have to change it everywhere if my policy
> changes.
>
> Perhaps some little plug-in class express the permission policy, and
> then changing it in certain instances would merely be a metter of
> overriding the class and somehow attaching the new policy instance to the
> object/resource.
Oh, of course this would be packaged up in various functions. It might
be like:
def canaccess(object, actor, action):
if hasattr(object, '__restrict__'):
result = object.__restrict__(actor, action)
if hasattr(actor, '__allow__'):
return result or actor.__allow__(object, action)
else:
return result
elif hasattr(actor, '__allow__'):
return actor.__allow__(object, action)
return 1
Actor might be a user (as in ACLs), a process (as with capabilities), or
an explicit permission object (also like capabilities).
> > > On Tuesday 20 November 2001 09:28 pm, Ian Bicking wrote:
> > > > In the more general sense, you might want to have relations. A person
> > > > can "own" something, perhaps another person is the "creator", or
> > > > "manager", etc. I suppose that's what you were thinking of as
> > > > roles...? Ownership could just be another role.
> > > >
> > > > Okay, I think we've got three ideas of roles just in this one email.
> > > > Damn terminology.
>
> The lowest level are objects/resources. I prefer the term object,
> keeping in mind that we're not talking about every single Python object,
> but only the ones that are "significant" in the app's security model:
> Customer, Widget, SalesOffice, etc. Python objects that are private to
> one of these significant objects need not be dwelt on, since they just
> "go along for the ride". One problem with the term "resource" is that
> external OS resources (file, window, etc) are also called "resources".
Well, not only aren't all objects controlled by permissions, permissions
act on something more abstract. All the objects in a system die when
the system is restarted (i.e., the AppSerter is restarted). The
permissions weren't references those specific instances that existed.
(Though, if you are using the ZODB, you could say that they were
attached to specific objects)
Anyway, with Webware they were probably referencing something more
abstract. A customer isn't an object -- the customer object comes and
goes. The customer is a class and parameters.
> The next level up are actions, specific to each object/resource:
> WidgetOrder.View, WidgetOrder.Cancel, WidgetOrder.Update, etc.
Of course, if we consider functions to be first-class objects, then
actions are just methods, which are just objects themselves. OTOH, not
every method will be restricted, and (maybe) not every action will be a
method (though I can't think of an example of that).
> The third level are roles/groups. Abstract names like "InferiorPeon",
> "CustServiceRep", "Manager", "God", etc.
>
> Users belong to groups/have roles. Groups/roles may also belong to
> groups/roles (per Tavis' suggestion). Here, the group terminology
> parses better in English.
>
> Permissions are the linkage between a role/group and an action. A
> role/group has permissions to several actions. Or one can just call
> the actions themselves "permissions".
>
> Ownership is an orthogonical layer Zope has (now) but MySQL doesn't.
> I would avoid adding it as long as possible. We've already seen several
> conflicting meanings for "ownership":
> 1) Which user(s) may change an object's permissions. (Tavis)
> 2) To support three independent sets of permissions: user/group/other. (Unix filesystem)
> 3) Some esoteric thing to plug a security hole. (Zope)
>
> > Resources are parts of projects.
> > Users have roles inside with respect to different projects.
> > Permissions are a mapping of role->(resource class, action)
>
> Similar to what I'm saying, I think.
No, quite different I think. In this system you aren't a "Manager", you
are a Manager OF something. That's more specific. And when a new
project X is added, I don't want to create a new ManagerX, EditorX,
PeonX group -- projects should be able to come and go easily, and
creation of projects (or subprojects) should not require special
authority.
So the roles are considerably different -- they are much more granular,
really, because they indicate a class of objects that they relate to.
Also, resources are classified, they aren't directly attached to
permissions. Resources might be classified into projects, or more
abstractly (e.g., "financial").
Then the mappings are stored entirely seperately and centrally. They
are not attached to users OR to resources.
> > The resource classes are a bit fuzzy in my mind yet, but I think this is
> > equivalent to declaring a resource, say, "confidential", "financial",
> > etc.
>
> Yes. These would prob'ly map to actual Python objects, even if they are
> just "empty" convenience objects.
>
> > But anyway, there needs to be a way for one user to say, "for this
> > activity, this person can act with my authority."
>
> Zope proxy roles alert! Zope proxy roles alert!
>
> Isn't it possible to do this with permissions only? The delegate only
> needs your permissions, they don't have to "act as you" as a separate
> concept per se. Allowing users to extend their permissions onto others
> ("grant/revoke") would effectively do the same thing, no?
>
> Proxy roles aren't evil per se, but they do add a whole lot of
> complication to the model, and prob'ly make ownership more necessary
> than it would otherwise be. So I'd rather make sure we really need them
> before adding them.
I hadn't known Zope had proxy roles. I get the impression you don't
like them?
I wasn't thinking of becoming someone, really, or giving someone your
identity. Rather, I was thinking of giving someone your authority --
presuming authority was an abstract notion/object apart from user.
So you might say "give person X my permission Y and Z", not "let person
X be me".
> > Capabilities have
> > some ideas about doing this -- well, actually I guess that's how all
> > permissions are aquired in a capabilities-based system.
>
> Dunno what "capabilities-based system" is...
I put some links on the Wiki, in UserHandlingProj, if you are curious.
Basically, in a capabilities-based permission system, each process has
"capabilities", which are essentially permissions. The process can be
given new capabilities by other processes, or when it is started up, and
the process can choose to do something with only a subset of its
capabilities. It makes restricted execution fairly easy, for instance.
This is in contrast to ACLs, where a process simply is doing something
for a particular user. There isn't any granularity, because the user
either chooses to run the process as himself, or not. Also, the process
can't be specific about the permission it is trying to use -- for
instance, it cannot choose to do something with a subset of the user's
permissions.
Anyway, that's capabilities for you (for the most part).
Ian
|