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.
> > - How should permissions be archived? Particularly in MiddleKit.
> >
> > - Permissions should obviously speak of roles. Should they also be able to
> > speak of specific users?
>
> Well, it's a big pain if there isn't an escape for those few instances
> when the normal process deviates. While they are seldom long-term, in
> the short-term user-specific permissions are conventient.
>
> > > And how about the term 'resource' rather than 'object'?
> >
> > I think this adds another conceptual layer that will obscure more than
> > enlighten. At least that's my thoughts until I see some text that spells
> > things out some more.
>
> I think the only problem with object is that it is more granular than
> most (well, all) permission systems are likely to be. Probably every
> resource will be wrapped in an object, if it isn't already an object,
> but every object will not be a resource in terms of having permission
> restrictions.
>
> Also, resources may actually be more like a list of parameters and a
> class -- the resource isn't identicle to the particular instantiated
> object that represents it at any one time. So you can't use id() to get
> the ID WTO permissions.
>
> > 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".
The next level up are actions, specific to each object/resource:
WidgetOrder.View, WidgetOrder.Cancel, WidgetOrder.Update, etc.
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.
> 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.
> 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...
--
-Mike (Iron) Orr, [EMAIL PROTECTED] (if mail problems: [EMAIL PROTECTED])
http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
