launchpad-dev team mailing list archive

[Tim Penhey <tim@xxxxxxxxxx>]

On Thu, 27 May 2010 01:37:36 Bjorn Tillenius wrote:

Firstly thanks for the considered reply.

My primary concern is around efficiency of the queries.  We already have issues 
with query times and I'd hate to see them become even worse.

Also, I'm keen on seeing the ACLs reduce the overall complexity of the system, 
not making it worse.  Having all the complexity in one place (like the ACL 
subsystem) is fine, but I'd not like to see the complexity littering all over 
the codebase.

I'd be happy to get more hands on with the implementation and design if 
needed.

> On Wed, May 26, 2010 at 10:26:33AM +1200, Tim Penhey wrote:
> 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.

If we are only ever storing grants, and not revokes, then this is probably ok, 
but should be documented.
 
> > 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 likely to get rid of the '.private' attributes for bugs, branches, 
teams et al?

That flag is good for unauthenticated access, but with the ACLs it would be a 
denormalisation where if there are any ACLs at all, the object would be 
considered private.

 
> > 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.

Are we going to support injecting ACLs over existing work?  So being able to 
add a limited VIEW permission over some existing projects code and suddenly 
all their branches are effectively private?

This may well have follow on impact for things like the revision cache which 
has specialisation for public and private revisions.  Public revisions can be 
found in feeds, but private ones can't.

> > 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.

I think one of the very tricky bits will be this 'partial private' bit where 
you can see a bug but not the project itself.

Tim