If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

strict_isolation in post_bug should also check can_see_product

RESOLVED FIXED in Bugzilla 3.2



Creating/Changing Bugs
11 years ago
9 years ago


(Reporter: Max Kanat-Alexander, Assigned: Wurblzap)


Bugzilla 3.2
Bug Flags:
approval +



(1 attachment, 1 obsolete attachment)

710 bytes, patch
Frédéric Buclin
: review+
Details | Diff | Splinter Review


11 years ago
1) Turn on strict_isolation.
2) Create a product that's mandatory/mandatory on any group.
3) Create a bug that's assigned to somebody not in that group. Or with a QA
   Contact who's not in that group. Or a CC-list member who's not in that
4) Bugzilla lets you.

  This is because we check can_edit_product in post_bug when we really should also be checking can_see_product.

Comment 1

11 years ago
Created attachment 234840 [details] [diff] [review]
Assignee: create-and-change → wurblzap
Attachment #234840 - Flags: review?

Comment 2

11 years ago
Humm... wait, please read bug 309681 comment 7 from joel first:

"From my standpoint, we want to prevent the addition of any user who would
violate a CANEDIT restriction on a bug.  It is less a matter of keeping the user
from seing the bug as it is to keep the others who can see the bug from seeing
the user."

This would make this bug to be invalid.

Comment 3

11 years ago
joel, what is your initial intention? There seems to be some contradition between being able to access/see/view bugs in a product and being able to edit bugs in this product.

There is no relationship between edit and view, i.e. all 4 combinations of edit/view are possible. Which ones are we interested in with this strict_isolation feature?

FWIW, I don't think this is a security bug, but a policy bug.

Comment 4

11 years ago
I'm OK with further tightening it so the user has to be able to both see and edit the product.  We just have to make sure that we require both rather than substituting the seeing for editing.

I'm not sure if we want to handle this as a security bug, though.  Should we?

Comment 5

11 years ago
No, it's not a security bug, for the reason that we didn't intend to make sure the user could see the product. So post_bug.cgi (and probably other scripts too) behaves correctly.
Group: webtools-security

Comment 6

11 years ago
Comment on attachment 234840 [details] [diff] [review]

bitrotten due to (massive) post_bug.cgi changes. (likely) see Bugzilla/Bug.pm instead.
Attachment #234840 - Flags: review? → review-

Comment 7

11 years ago
I don't want to break 2.22 with this bug.
Target Milestone: Bugzilla 2.22 → Bugzilla 3.0

Comment 8

11 years ago
Created attachment 261846 [details] [diff] [review]

Attachment #234840 - Attachment is obsolete: true
Attachment #261846 - Flags: review?(bugzilla-mozilla)

Comment 9

10 years ago
Comment on attachment 261846 [details] [diff] [review]

r=LpSolit assuming you tested it successfully on Bugzilla 3.1.2+ (just in case something weird changed in the code these last few weeks).
Attachment #261846 - Flags: review?(bugzilla-mozilla) → review+

Comment 10

10 years ago
Marc, please comment when you have tested your patch on the current trunk. Holding approval meanwhile.
Severity: major → normal
Flags: approval?
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2

Comment 11

10 years ago
Ok, I tested assigning a new bug to a user not in a mandatory group of the product, and it did prevent me from doing it. Switching strict_isolation off, I'm allowed.


10 years ago
Flags: approval? → approval+

Comment 12

10 years ago
Checking in Bugzilla/Bug.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Bug.pm,v  <--  Bug.pm
new revision: 1.205; previous revision: 1.204
Last Resolved: 10 years ago
Resolution: --- → FIXED


10 years ago
Keywords: relnote


10 years ago
Blocks: 399654

Comment 13

9 years ago
Added to the release notes for Bugzilla 3.2 in a patch on bug 432331.
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.