[Launchpad-dev] Permissions for creating private objects
Hello all,
We're on an arc to enable a bot of ours to create private PPAs for the
Software Center with the least possible privilege.
Our current implementation approach, blessed by Robert, is to create a
new celebrity that governs creation of commercial private PPAs and
to allow members of this team to create them.
However, before we reached that point, James Westby and I did some
thinking about the problem and I reckon it's worth sharing with
Launchpad developers more generally.
1. ``launchpad.Append`` is the correct permission for creating new
items in a collection
I say Append and not Edit, as Edit seems to be more about modifying
existing objects. It's the difference between PUT and POST that I
understand that REST-heads make. I think there's a lot of
inconsistency in Launchpad.{{fact}}
Then, trying to create a PPA or a junk branch for a team would require
launchpad.Append on the archives and junk_branches collections in that
team, and if I'm not in the team I don't have the permission. Simples.
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.
jml
[1] Or you can have a secure constructor that wraps the real
constructor, calls that, wraps the object in its security proxy and
sets the attributes there, and then insist that all code calls the
secure constructor. Ugh.
___
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Permissions for creating private objects
On Tue, 1 May 2012 11:00:26 +0100, Jonathan Lange j...@mumak.net 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 ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Permissions for creating private objects
On Tue, May 1, 2012 at 3:04 PM, James Westby jw+deb...@jameswestby.net wrote: On Tue, 1 May 2012 11:00:26 +0100, Jonathan Lange j...@mumak.net 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. Yes. Everything you just said. jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
