launchpad-dev team mailing list archive

[Bjorn Tillenius <bjorn@xxxxxxxxxxxxx>]

On Wed, May 26, 2010 at 10:26:33AM +1200, Tim Penhey wrote:
> Hi Bjorn (and other interested parties),
> 
> I have a number of concerns, most of them around the fundamentals of how it 
> will all be implemented, efficiency of queries, how this will work with 
> collections and so on.
> 
> Firstly though, I was a little confused by one of the first examples, and it 
> certainly seemed counter-intuitive.
> 
> > If you need to limit who can view the project, you can grant permissions
> > to specific people or teams::
> > 
> >     >>> project_acl.grant(VIEW, bob)
> > 
> >     >>> project_acl.has(VIEW, alice)
> >     False
> >     >>> project_acl.has(VIEW, bob)
> >     True
> > 
> >     >>> project_acl.grant(VIEW, alice)
> >     >>> project_acl.has(VIEW, alice)
> >     True
> 
> Before this we had shown that everyone had view access to the project, 
> including alice and bob.  Granting view permission for bob should not effect 
> alice.  In order for alice to not see it, we should have either revoked 
> alice's view permission, or revoked view for everyone.

I actually had an explicit revoke(VIEW, EVERYONE) in there before, but
since that is something that you have to do with the first grant, I
removed it. It seemed better to consider VIEW, EVERYONE as a special
case.


> Which brings me to another question.
> 
> What happens if we have:
>   view for everyone
>   view revoked for alice
> 
> Can alice see it because she is one of everyone?  How is exclusion going to 
> work.
> 
> Is it that if the user gets visibility through any team, they get view 
> permission?

Yes. The current system tracks only who has permissions. It doesn't
track who hasn't. So if you have VIEW for EVERYONE, you can't revoke
permissions for specific users. You have to revoke the permission for
everyone, and then add the users that should have access. It's a
limitation, but it makes things easier, and none of our current use
cases required "granting to a group of people, except for X."


> What permissions are we talking about here?  Just VIEW, and EDIT, or are we 
> going for CRUD (create, read, update, delete)?  What about admin and other 
> special permissions?

That hasn't been decided yet. The plan is to start with VIEW and
MODIFY_ACL in the first step, and then add more as is needed. There's no
built-in restriction on which permissions can be in there. (VIEW is used
for controlling who can see an object, and MODIFY_ACL is used for
controlling who can modify the ACLs.)


> Is this going to be a replacement for our security adapters or an enhancement 
> to it?  If it is an enhancement, do we know how yet?

The first step is to have this to be on top (or part) of the security
adapters. So we first check to see if the user is allowed by the ACL,
and then the reqular adapters will check everything else, like who can
write to the object, and so on.


> It was mentioned that subsystems (or applications) of Launchpad can have 
> different ACLs, but no example is given.  I'm curious as to how that'd be 
> implemented too.

I guess the best example here is to have a public project, but private
branches. As I mentioned before, an object's ACLs are inherited by its
children. For example, a project's branches can be considered to be part
of the project itself, so they have the same ACLs as the project. I.e.,
we have a chain, Branch -> Project. We we create a branch, we look at
the branch's ACL parent, and use the same ACL as the parent. To
have private branches, we need to override the ACLs for all the branches
that will be created. IN order to do this, we insert a virtual object
"Branches" in the chain, Branch -> Branches -> Project. We now override
the ACL for Branches, to say that only a limited set of people have VIEW
permissions. When we create a branch now, it will look at its ACL parent
"Branches", and use the same permission.


> Also, the example shows privacy on a bug task.  How does this relate to the 
> but itself?  What if a bug has multiple tasks, but some are private?

The bug itself doesn't have any ACL defined, since it doesn't have a
single parent. If you have a private bug task, and add another bug task,
that ones that will be able to view the new bug task, will also be able
to see the bug description. They won't necessarily have access to see
the old bug task, though, meaning that when they look at the bug, they
will either not see the old bug task at all, or they will see that there
is a bug task, but it won't see any information about it. Or they will
be given permission to see the old bug task explicitly. It's up to the
programmer to decide how to handle this.


-- 
Björn Tillenius | https://launchpad.net/~bjornt