Forbidden error when trying to mark a bug as private

Bug #61531 reported by Matthew Paul Thomas
4
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
Critical
Graham Binns

Bug Description

OOPS-1978QASTAGING34

Using the +secrecy form to change a bug one is not subscribed to to a private bug causes the page render after the form submission to fail because the bug is inaccessible.

Discussion
==========
Setting privacy is currently an unprivileged operation, and this is problematic in a couple of places.

For the unsetting case commercial projects probably don't want can-view-the-bug to equate to can-decide-its-public.

For the setting case, taking a bug private partitions it off from its normal community, so again letting anyone decide that it should be hidden is probably too broad.

Its not clear who should be able to decide that a bug should be private.

Solutions
=========
One way of fixing this bug is to just subscribe the person marking it as private.

Another way is to prevent marking existing bugs as private (or security) unless the person doing the marking is affiliated with the project in some sensible fashion.

Related branches

Revision history for this message
Diogo Matsubara (matsubara) wrote :

To reproduce using sample data:
1. Logged in as Sample Person open: http://launchpad.dev/distros/debian/+source/mozilla-firefox/+bug/3/
2. In "Visibility/Security" check the "Keep bug confidential"
3. Forbidden error.

Changed in malone:
status: Unconfirmed → Confirmed
Revision history for this message
Brad Bollenbach (bradb) wrote :

mpt, what about greying out the option, like:

[ ] This bug should be visible only to its subscribers
/!\ You must _subscribe to this bug_ to set this option

?

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

But I didn't want to subscribe to it.

Revision history for this message
Brad Bollenbach (bradb) wrote : Re: [Bug 61531] Re: Forbidden error when trying to mark a bug as private

On 15-Oct-06, at 2:30 AM, Matthew Paul Thomas wrote:

> But I didn't want to subscribe to it.

Should a non-subscriber be able to make a bug visible only to its
subscribers?

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

It's not making it visible only to subscribers, it's making it visible only to subscribers plus the security contact. I should be able to do that if I am either a subscriber (which I wasn't), or a member of the security contact team (which I was).

Revision history for this message
Brad Bollenbach (bradb) wrote :

On 18-Oct-06, at 3:42 AM, Matthew Paul Thomas wrote:

> It's not making it visible only to subscribers, it's making it visible
> only to subscribers plus the security contact. I should be able to do
> that if I am either a subscriber (which I wasn't), or a member of the
> security contact team (which I was).

Currently it's "visible only to subscribers". And you weren't a
security contact for the example you gave.

But I agree that if privacy does implicitly allow security contacts
to view bugs, and you were a security contact, you should have been
allowed to change it. I still think a greyed out widget would be more
helpful to explain why it's sometimes available and sometimes not.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

Sorry, I got the bug number wrong in my description. It was a Launchpad bug, for which I am (a member of the team that is) security contact.

description: updated
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

(To do: Check whether the security contact problem still happens, and if so, split it out into a separate bug report.)

Curtis Hovey (sinzui)
Changed in launchpad:
status: Confirmed → Triaged
importance: Undecided → Low
Revision history for this message
Robert Collins (lifeless) wrote :

If this is still present we will get an OOPS due to the 404-from-lp-action logic, so I've retriaged it appropriately.

Changed in launchpad:
importance: Low → Critical
tags: added: oops
Revision history for this message
Leonard Richardson (leonardr) wrote :

I was able to duplicate a related problem, but there was no OOPS, so I'm re-triaging back to Low.

Logged in as Sample User, I went to https://launchpad.dev/debian/+source/mozilla-firefox/+bug/3, and clicked on the edit button by "This report is public". I checked "This bug report should be private" and saved the change. The change went through with no error.

At this point I could no longer see the bug. Reloading the page gave me a fake 404 error. Using the other Ajax forms instead of reloading the page gives an unfriendly error "Object: , name: u'3'" that I happen to know corresponds to a 404 error.

It seems strange that Sample User has permission to make the bug private but not permission to see the bug when it's private. But if this is the correct behavior, it should be handled more gracefully.

Changed in launchpad:
importance: Critical → Low
Revision history for this message
Robert Collins (lifeless) wrote :

leonard - I suspect that your local error dir will be accumulating OOPSes when you're getting those 404s from ajax.

Curtis Hovey (sinzui)
tags: added: privacy
removed: oops
tags: added: 403
Revision history for this message
Robert Collins (lifeless) wrote :

Trivially reproduced on qastaging:
https://bugs.qastaging.launchpad.net/libdbusmenu-qt/+bug/633339/+secrecy, tick 'private' and save.

tags: added: oops
description: updated
Changed in launchpad:
importance: Low → Critical
Graham Binns (gmb)
Changed in launchpad:
assignee: nobody → Graham Binns (gmb)
status: Triaged → In Progress
Revision history for this message
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
Changed in launchpad:
status: In Progress → Fix Committed
Graham Binns (gmb)
tags: added: qa-ok
removed: qa-needstesting
William Grant (wgrant)
Changed in launchpad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.