PPA upload permissions should be decoupled from its team membership.

[Michael Casadevall]

I noticed this awhile ago, but I didn't think to file a bug on it.

On projects that have a PPA, you can upload freely to it if your a member of that group, and on projects that have free registeration, this can be very dangerous. Take the 5-a-day project, and then it just takes one person to upload a well placed rm -rf /, and suddenly every user is screwed.

[Celso Providelo (cprov)]

Hi Michael,

Don't you think your are overestimating this issue ?

I failed to see how a restricted-membership team helps to avoid malicious uploads. Quality assurance is still an user responsibility, he decides whether to enable a specific repository or not.

OTOH, it's important to note that it would be relatively simple to us, at this point, to decouple PPA upload permission from team membership. However we have to investigate if this extra-level of indirection really brings the benefits we are expecting.

For now, if you guys agree, I don't this bug as a private/security vulnerability. Can it be made public ?

[Michael Casadevall (mcasadevall)]

Restricted membership isn't a problem, if you make a person a member of a team, then the admin(s) trust them to do an upload. The 5-a-day group is example case:

https://edge.launchpad.net/~5-a-day/+archive

There are roughly 150-ish users on it. Anyone can register an account, join this team, add a GPG key, upload replacing the existing package with a malicious command, and quite possibly screw users over. Granted, you could put the PPA in a separate team, but having PPAs on teams with open membership seems kinda dangerous ...

[Michael Casadevall (mcasadevall)]

Going one step futher, I can simply upload a package with a version greater then something in the Ubuntu archive and have it clobber on upgrade.

i.e., upload grub-666, and watch people's computers fail to boot.

[Julian Edwards (julian-edwards)]

I think this is more of an end-user issue than a Soyuz issue, we don't want to start predicting what's good and bad for PPA usage and force early decisions on people by way of preventing PPA creation for open teams.

However, decoupling the upload permission from team's membership is definitely something that I want to do for a couple of reasons anyway, so we'll look into that.

[Christian Reis (kiko)]

The grub-upload issue may be valid but it doesn't have much to do with permissions -- any uploader to a PPA can effectively bump a version of an important package, and at any rate as a PPA user you are acknowledging the risk of downloading packages uploaded by potentially untrusted sources. That's part of the contract.

I am still curious as to what Michael finds exactly problematic. Is it that there are PPAs for open membership teams? Or is it that specifically the 5-a-day team is open membership?

[Michael Casadevall (mcasadevall)]

When you access a PPA, the members of that team are the archive administrators; you are hoping that none of them are evil by screwing you over with a bad package such as grub and such. When you have an open team however, its like saying that anyone can join that team and be an archive administrator of that PPA, and upload something without anyone checking it. On open teams, like 5-a-day, who have a large number of users on their PPA, this could be disastrous if someone uploaded an evil package.

[Julian Edwards (julian-edwards)]

See also bug 382793, which is for adding additional upload permissions to people outside the PPA team.

[Soren Hansen (soren)]

I would find this very, very useful indeed.

In OpenStack, we have a great, big ~openstack team for anyone who's interested in OpenStack. Our official mailing list the one set up for this team. We'd like a project-wide PPA for releases (the individual components' core teams already have subproject-specific PPAs), and it would be ideal if we could have this PPA be under this team (easier to remember and ppa:openstack/release is way prettier than ppa:openstack-ppa/release), but obviously we don't want the whole world to be able to upload to it.

[Robert Collins (lifeless)]

@soren a project PPA might be better for what you want. Launchpad has
a pretty strong team-owned-assets-are-team-administratable model, and
I think this would fly directly in that, adding confusion.

[Julian Edwards (julian-edwards)]

FWIW making this happen would be pretty easy, we'd just need to add a UI to administer the permissions. You can already change them over the API.

Once that's done we just migrate the existing team memberships into explicit permissions and then turn off the "owner-can-upload" one.

@Rob - he's not talking about administering, he's talking about uploading which is an entirely different thing. We definitely should make this change, a lot of people ask for it.

[Robert Collins (lifeless)]

On Wed, Jun 8, 2011 at 9:42 AM, Julian Edwards
<email address hidden> wrote:
> @Rob - he's not talking about administering, he's talking about
> uploading which is an entirely different thing.  We definitely should
> make this change, a lot of people ask for it.

Its not really that simple though is it: the owning team if they can
administer can add themselves as an uploader, upload and remove
themselves.

So yes, we could make a simple change but I don't think it would meet
the stated use case robustly : this is a case where we should look
beyond the direct question we're being asked, IMNSHO.

[Soren Hansen (soren)]

Robert, I wasn't familiar with the concept of project PPA's. Do they exist or are they something on Launchpad's roadmap?

Julian, sorry, are you saying I already have this capability, only it's not exposed in the UI, but only in the API?

[Robert Collins (lifeless)]

On Wed, Jun 8, 2011 at 9:20 PM, Soren Hansen <email address hidden> wrote:
> Robert, I wasn't familiar with the concept of project PPA's. Do they
> exist or are they something on Launchpad's roadmap?

They are a desired feature we would like to do. They are partly
blocked by the mistake of having ppa:foo refer to a username without
the ~ :(.

[Soren Hansen (soren)]

As a workaround I thought I could (ab)use archive_permissions to make this work, but I guess not. I don't see any way in which I could revoke the team's members' upload privileges, only ways to grant upload privileges to people outside the team.

[Julian Edwards (julian-edwards)]

On Wednesday 08 June 2011 10:20:34 you wrote:
> Julian, sorry, are you saying I already have this capability, only it's
> not exposed in the UI, but only in the API?

You can set uploaders outside the owning team, yes. You can't prevent people
in the owning team from uploading though.

The uploaders outside the owning team also get extra email announcements about
any uploads.

[Robert Collins (lifeless)]

so, we can add extra uploaders, and we have a rule in LP that open teams cannot have PPAs. Teams that own things having full control over them is a core part of LP and not one we'll fiddle with arbitrarily ;)

[Julian Edwards (julian-edwards)]

Ownership and upload permissions are completely orthogonal in Soyuz, we need to fix this.