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
