launchpad-dev team mailing list archive

[curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

Hi Ian.

I am not feeling well. I am exhausted and restless, so I think others
might want to speak about this issue and my thoughts on the matter.

On 05/01/2012 07:25 AM, Ian Booth wrote:
> Consider a project with some branches. A user's access to the project
> has been revoked by the project owner, so the user needs to be
> unsubscribed from the project's branches.
> 
> The unsubscribe job is initialised and the requestor is recorded (the
> project owner). For each project branch the user is subscribed to, the
> job calls:
> 
> branch.unsubscribe(user, requestor)
> 
> unsubscribe does:
> 
> subscription.canBeUnsubscribedByUser(requestor)
> 
> which does:
> 
> permission_check = BranchSubscriptionEdit(self)
> return permission_check.checkAuthenticated(IPersonRoles(user))
> 
> which does:
> 
> return (user.inTeam(self.obj.branch.owner) or
>         user.inTeam(self.obj.person) or
>         user.inTeam(self.obj.subscribed_by) or
>         user.in_admin)
> 
> So, we have a potential permissions conflict. The project owner who has
> permission to revoke access may not have permission to unsubscribe a
> user from a project's branch.
> 
> We could put in a boolean variable to the unsubscribe call to force the
> operation to succeed? Or we could add
> user.inTeam(self.obj.branch.product.owner)
> to the permission check? (but this fails for private branches in my test
> case, so more thought needed).

I expected an issue like this. I do not have an authoritative answer
because I think there are two axis of change happening in Launchpad at
this moment. Regardless of where we are in this change, we know the
operation is permitted -- maintainer do have the right to unsubscribe
untrusted users.

We definitely want to change the security checkers to ensure the
celebrity or maintainer have permission to complete their task. Who/what
is doing this change and when exactly it happens is not clear.

Axes
1. Job runner -> celery
2. multi-tenancy -> projects own data

When I wrote jobs in the past, the job ran as a celebrity, such as the
janitor, which is given permission to complete the task for the user. I
think some security checkers continue to use celebrities for
translations and registry process.  I do not know if celery is running
as the proxy celebrity or as the user that initiated the change.

In the post multi-tenancy epoch, we know the project maintain does have
the right to unsubscribe users to avoid disclosing private data to
untrusted users. When maintainers look at the private data that is
shared with users *right now* on production, that might be concerned. eg
Maintainers can follow the "Sharing" link on their projects page to see
starting information.

Launchpad has a problem *right now* where a project maintainer must ask
a WebOps to remove a user via IRC to ensure the subscriber does not see
the visibility change. Launchpad has a few hacks in place that ensure
that changes made by WebOps do not notify team members or subscribers
because we recognise organisations have some rights that are preeminent
over people.

I would like to be able to unsubscribe users from private bugs and
branches right now using the bug and branch pages. But this change might
be premature. There is a conflict between public data and private data.
I do not think I have the right to unsubscribe users from public data.
How do we handle the case where the data *will* be private, *and* I need
to unsubscribe users to make it private? We may only want the
preeminence rule to apply to action from the sharing pages for now.

Maybe we want maintainer subscriptions to from public data to inform the
users, but the action is silent when private data is involved? This does
not fully address the transition case. This operation must work over API
and UI. Maybe we need to support email.

-- 
Curtis Hovey
http://launchpad.net/~sinzui

Attachment: signature.asc
Description: OpenPGP digital signature