[Zope-dev] Owner Role -- clarification needed

[Brian Lloyd]

> Hi,
> 
> I'm playing around with building a cookie-based 
> authentication Zope product, and 
> I've been learning a lot about users, roles, local roles and 
> proxy roles ...
> So I was wondering if my understanding of the proposed Owner 
> role (given that
> documentation is very scanty) is correct, incorrect, or 
> simply needs clarification.
> 
> The thing is, my setup is working, but who knows what bugs 
> may lie just around 
> the corner, merely because I misunderstand the concepts... (and since
> I'm dealing with an authentication product, is *_specially_* 
> important).
> 
> I'm using the Owner role in the context of allowing a user to 
> change his/her 
> passwords. I suppose I could create another role to fulfill 
> this, so its really
> not a big deal if I shouldn't be using the Owner role for 
> this purpose:
> 
> So this is my setup :
> 
>      1. For a given Folder for which I am creating my 
> cookie-based UserFolder 
>         (named acl_users, of course) I create a role known as 
> a cookieLoggedUser. 
>         All users that are created in acl_users have the 
> cookieLoggedUser 
>         role automatically added to their roles profile (and 
> cannot be deleted).
> 
>      2. In this Folder, there are dtml methods to allow you 
> to login/logout etc. 
>         (they are working fine and are of no importance to 
> the issue at hand)
>         When users log in, they acquire the role of 
> cookieLoggedUser (along with 
>         the other roles defined for their user id, of course).
>  
>      3. the acl_users permissions are modified to allow the 
> 'Owner' role
>         the privilege to "manage_users". (Is this advisable 
> or is this a big 
>         security hole?)
> 
>      4. I have a DTML method that displays the Change 
> Password form (it submits
>         the page to itself and I use a hidden form variable 
> to check whether 
>         it should process the form or not). 
> 
>      5. This method has its permissions
>         set so that only users with the cookieLoggedUser role 
> can 'view' it or
>         'access contents information'. This means that 
> Anonymous users can't see
>         this page unless they log in first, in which case 
> they acquire the
>         cookieLoggedUser role. 
> 
>      6. The processing DTML code calls the acl_users methods 
> to change the
>         password (and has safeguards against logged-in users 
> from changing
>         anybody else's passwords except their own). Because 
> they access
>         the acl_user's methods which require 'manage_user' 
> privileges, 
>         I gave this method a proxy role of 'Owner' so that it 
> can execute
>         these privileged methods.
> 
> Some notes:
> 
>      a. I don't *_have_* to use the Owner role for this 
> purpose. (I could easily
>         create another role expressly just for accessing the 
> acl_users privileged
>         methods and my system would still work) but I do want 
> to understand
>         if the 'Owner' role is meant to be used in this 
> context or not.
> 
>      b. If you give a user the Owner role, (along with the 
> view management 
>         screens, of course), you allow him/her the privilege 
> to 'manage_users'.
>         My understanding is that you normally *_dont_* give 
> this role out to
>         any ordinary user? 
>   
>         If this is incorrect, then my whole theory sinks down 
> the drain...
>         OTOH, if I'm incorrect, then just what the heck is 
> the 'Owner' role for?
>         
>      c. I've thought about possible security holes and think 
> (given the levels
>         of security HTTP protocols can give, of course) it's 
> fairly secure. It
>         could be made more secure by encrypting the cookie 
> better and providing
>         a secure channel (i.e. SSL).
> 
>      d. I'd really like to hear the opinions of those in the 
> know, especially about
>         how we should use the 'Owner role' (of course, we can 
> use it for any purpose
>         we want to, but I want to know the *_right_* way to 
> use it, i.e., the way it's
>         meant to be used).
>  
> Thanks in advance,
> 
> Butch Landingin


Butch,

The theory behind the "Owner" role is that:

  o when a user creates a new object, he/she automatically
    gets the local role "Owner" for that object.

  o As a site manager, you can set reasonable permissions
    for the "Owner" role at the top of your site, which
    will be acquired when folks work with objects that they
    have created.

This means basically that you can reasonable laws of ownership
(what people can do with objects that they have created), without
having to visit every object that someone creates *and* without
necessarily giving them the ability to modify security settings
themselves.

For example, lets say that you create a folder called "home" on
your site. For the security settings for "home" you say that
the "Owner" role can Create Documents Images and Files, Edit
Docs Images and Files and Delete objects. Now you can create 
a new Folder inside of "home" for each user who should have
a home area, and give them the local role "Owner" in that Folder.

Having done that, your users can each create, edit and delete
document in their own folders - but they *can't* go over and
mess with their neighbor's Folder, because they only have the
"Owner" role locally in their own Folder.

The situation you describe above doesn't sound like it needs
to use any of this. In your situation, the best (and most secure) 
approach would be to avoid giving any of your users "manage users" 
permissions directly. 

Just give the "Manager" proxy role to your password-changer 
form and make sure that "Manager" has the manage users
permission. This way, it is effectively actually your *form* 
that has the permission to fiddle with user data, not the
users themselves. The form logic itself should be able to
ensure that a user can only change his own password.


Hope this helps!


Brian Lloyd        brian@digicool.com
Software Engineer  540.371.6909              
Digital Creations  http://www.digicool.com