Subscription policy inherited from parent team member

Bug #700724 reported by Michael Wood on 2011-01-09
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Ubuntu Florida LoCo Team

Bug Description

Ubuntu-uk's launchpad team is a member of "approved loco teams", it makes sense for approved loco teams to have a moderated subscription policy but not for "ubuntu-uk loco team".

We deliberately want the loco team to be an open team, however on trying to set this I get the error "The team subscription policy cannot be Open Team because one or more if its super teams are not open."

As team owner I would also have expect to be contacted about this change.

Related branches

Michael Wood (x3n) wrote :

and "Ubuntu Local Community Teams"

Hi, yes I can see that use case.

We have a bit of a planning meeting happening week after next, but
I'll give you guys some context for why the change was done and what
we need to achieve in giving you what you need.

Access granted by teams in Launchpad is transitive: that is, if
ubuntu-approved-loco teams has a PPA, bug triage rights, vote-holding
rights etc, then all members of ubuntu-approved-loco-teams, or members
of teams that are members of ubuntu-approved-loco-teams or members of
teams that are members of teams that are members of
ubuntu-approved-loco-teams and so forth - they all get the same

PPAs have the ability to install software with little warning, as
root, on users machines; bug triage can be exceedingly noisy, security
contacts can see bugs with CVE details (and the associated legal

In a very pragmatic sense, any team with a sub-team that is 'open' is
*effectively* open. What we wanted to do was:
 - close some specific security holes (PPA's, security contacts,
commercial subscription tickets)
 - prevent surprise on the part of our users if something they thought
was 'controlled' became de facto uncontrolled. E.g. a restricted team
with a restricted subteam that the subteam owner subsequently opens.

Launchpad isn't intrinsically good at modelling organisational layouts
- that is a nonfunctional split (which is what you seem to be
modelling here: the N loco teams are stamped 'approved' but their
members are not vetted at all - functionally the *individuals* that
are members of any loco team are able to do anything anything the
parent team can).

Perhaps you could describe what your needs are (for instance why do
you need to limit the number of loco teams if the teams are
open-access?) ?


Curtis Hovey (sinzui) wrote :

Sorry Michael.

I did indeed plan to to announce the change. I let other work distract me. About 100 projects were updated, most were in the chain of loco teams.

We might want to consider a new subscription policy that means the team cannot own secure artefacts, but controls its immediate artefacts. The list implies that loco teams are the only group that needs this.

Changed in launchpad:
status: New → Triaged
importance: Undecided → Low
tags: added: disclosure
Robert Collins (lifeless) wrote :

Another thing we could do is model organisations directly - namespace
ownership, membership restricted by membership in an organisation -
asset ownership likewise etc.

Laura Czajkowski (czajkowski) wrote :

Perhaps in future if changes like this are going to be made an email to the Ubuntu LoCo Contacts list would really go down well as this effects many LoCo teams and there is a language barrier there so be nice to find out before hand rather than trying to find out via IRC channels what is going on. Thanks for the update though.

Curtis Hovey (sinzui) on 2011-01-19
tags: added: teams
Nathan Handler (nhandler) wrote :

What about simply giving the parent teams the ability to toggle a setting that either allows or disallows sub-teams to be open when the parent team is closed? The setting could be to disallow by default (per the current behavior).

Curtis Hovey (sinzui) wrote :

a flag would be an exception that provides an opportunity to introduce security issues into the code. The SubscriptionPolicy is both what is checked in the system and what is used to define why the restrictions are in place. It needs to be clear to users and engineers when memberships and privileges are compromised.

The question remains should a compromised team ever be permitted to own a resource that needs to be secure such as a PPA, or needs moderation because a communities image can be smeared? I personally have joined more than 50 teams in the last year to gain edit access to the projects they own, I changed the project's license, description, and summary, then left the team. Many users might think that is unethical, but Lp let me do it.

Daniel Holbach (dholbach) wrote :

In reply to comment 2: The use-case of ~locoteams is pretty simple: have a list of LoCo teams that exist around the world. We don't necessarily want to know about each individual LoCo team member, but just about the existing teams. ( polls that list of teams for example.)

On the other hand do we encourage the sub-teams themselves to be open to invite new contributors in.

David Rubin (drubin) wrote :

I do not feel this has low priority!

This is a fundamental change that was made to the group policies and there was no documents/reports about this change.

More over LP/LP Admins did not communicate that this change would be pushed into effect.

IMHO this could be considered as a regression.

Charles Profitt (cprofitt) wrote :

I can understand the security ramifications, but I am not fond of the chosen solution. I do admit I am unaware of the internal plumbing so my idea may not be possible. I am curious if it is possible to:

1. have a 'flag' for the parent team to prevent inheritance of permissions?
2. add a level of member that has no permissions to perform teams tasks; many CMS systems have this 'reader' level vs. 'contributor', 'admin', and 'owner'.

I hope we can all work towards a solution that works for both sets of needs.

Leandro Gómez (leogg) wrote :

I'm with Rubin here. This is a regression and the priority should change. Making the teams moderated is not an acceptable solution.

And yes, this should have been discussed with the LoCo teams.

Curtis Hovey (sinzui) on 2011-01-20
Changed in launchpad:
importance: Low → Critical
milestone: none → 11.02
Curtis Hovey (sinzui) wrote :

We are separating the organisational (community and corporate) needs implied in this issue. This issue will be just about the operational needs to restrict users and teams from joining some teams in a hierarchy of teams. We will introduce a new TeamSubscriptionProlicy to describe a team that moderates direct membership, but the sub teams may be open. We are seeking a good adjective.

Laura Czajkowski (czajkowski) wrote :

Curtis, does that mean then that all sub teams in locoteams will be open to join and not be moderated?

Curtis Hovey (sinzui) wrote :

@czajkowski, yes. All subteams of ubuntu-approved-loco-teams may be OPEN, but ubuntu-approved-loco-teams itself will be DIRECT_MODERATED_ONLY. We need a better word for this new policy.

Curtis Hovey (sinzui) on 2011-01-24
Changed in launchpad:
assignee: nobody → Curtis Hovey (sinzui)
Curtis Hovey (sinzui) on 2011-01-24
Changed in launchpad:
status: Triaged → In Progress
Martin Pool (mbp) wrote :

Please, as part of fixing this story/bug, add something to the help wiki explaining how this works.

Curtis Hovey (sinzui) on 2011-02-01
Changed in ubuntu-florida:
status: New → Invalid
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
Changed in launchpad:
status: In Progress → Fix Committed
Curtis Hovey (sinzui) on 2011-02-04
tags: added: qa-ok
removed: qa-needstesting
Curtis Hovey (sinzui) on 2011-02-11
Changed in launchpad:
status: Fix Committed → Fix Released
mmgc84 (mmgc84) wrote :

When will LoCo teams be able to change subscription to open? I tried to change the policy to open a few minutes ago but the bug is still there

Nathan Handler (nhandler) wrote :

On Wed, May 18, 2011 at 2:34 PM, mmgc84 <email address hidden> wrote:
> When will LoCo teams be able to change subscription to open? I tried to
> change the policy to open a few minutes ago but the bug is still there

The two main Launchpad teams, ~locoteams and ~locoteams-approved, have
been set to be delegated teams [1]. However, if your loco team is a
member of some other moderated or restricted teams, you will be unable
to set it as open. You should check what teams your loco is a subteam
of, and then get in contact with the administrators of those teams to
sort this out.



Curtis Hovey (sinzui) wrote :

They can if the teams they are a member of are open or delegated. ~locoteams is already set to delegated, so direct members can become either delegated to open. Indirect members must ask their team super team to change. In your case, I see this on your +particpation page that many teams that are blocked because a super team is moderated of restricted. eg:

Paul Tagliamonte (paultag) wrote :

We posted to loco-contacts when we swaped over :)

Hope you find what you're looking for!!

Leandro Gómez (leogg) wrote :

I'm getting a bit frustrated with this and am about to close our Launchpad team. Bug #110108 won't let us change our participation in Restricted teams.

Laura Czajkowski (czajkowski) wrote :

I've joined #launchpad to talk to Curtis to see how best we can resolve this issue

Curtis Hovey (sinzui) wrote :

Which team do you want to make open? The general rule when changing a sub team's membership policy to be open or delegated is to ensure the hierarchy of super teams are also open or delegated. If you do not control the the super teams, you must contact the team owners. The top tier of loco teams were changed to delegated. I think the problem is in the middle tier of super teams. Since their membership policy was not changed in the last 6 months, we may have absentee owners. I know many teams want to to change their policy. I think the sub teams need to demand responsive owners.

I can several teams mid-tier teams listed on your +participation page that are moderated, but probably do not need to be. Teams with PPAs must be moderated or restricted, but these teams I see could/should *choose* to be delegated if they need to control how someone is a member of th team:

I think and are blocking many teams for having an open or delegated membership policy. Have these teams been contacted to change the policy to delegated? If the owner have not responded to requests, the community can request that a new team be made the owner that will provide leadership.

I see that can choose to be open or delegated now because the all the super teams are delegated.

There may be a few cases where teams have PPAs that will block the membership policy change. There are two ways of addressing this. Either delete the archive, or create a new team that for the hierarchy.

Curtis Hovey (sinzui) on 2012-06-26
tags: added: hardening
Curtis Hovey (sinzui) on 2017-05-15
Changed in launchpad:
assignee: Curtis Hovey (sinzui) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers