launchpad-dev team mailing list archive

[James Westby <jw+debian@xxxxxxxxxxxxxxx>]

On Tue, 1 May 2012 11:00:26 +0100, Jonathan Lange <jml@xxxxxxxxx> wrote:
> 2. zope.security has no way to declare that certain values of certain
> parameters require certain permissions
> 
> The big example here is 'private=True'. There's no way to declare this
> that I can see. You *have* to write code[1] that looks like:
> 
>   if private == True:
>       check_permission(SOME_PERMISSION, object)
> 
> 
> 3. Even were this solved, we need a different permission.
> 
> Say we had a "new_private" method that set private to True, then we'd
> need a permission other than launchpad.Append to govern it.
> 
> The required permissions are defined a bit like this:
>   $OBJECT.$ATTRIBUTE needs $PERMISSION
> 
> And people are assigned permissions like this this:
>   $PERSON has $PERMISSION on $OBJECT
> 
> So for our hypothetical object representing a person's PPAs:
>   PPAs.new needs launchpad.Append
>   PPAs.new_private needs ???
> 
> ~jrandom has launchpad.Append on his collection of PPAs, so they can
> call 'new' and I can't. What permission should 'new_private' require?
> 
> Say we used launchpad.Moderate or a new permission
> launchpad.AppendPrivate, then that would address the problem, but it
> would assume that we only ever have one level of entitlement per
> collection.
> 
> 
> I don't have any answers, conclusions or recommendations I'm afraid,
> so I welcome your thoughts even more than usual.

Would this be solved by having multiple collections?

Person.PublicPPAs and Person.PrivatePPAs, each of which can have a separate
Launchpad.Append permission.

A collection that glued them together could perhaps be used to limit the
impact of this to users and code that doesn't care about the
distinction.

This would seem to fall down if you need two orthoganal attributes
controlled by elevated permissions though.

Thanks,

James