editcomponents priv allows you to see/edit products you don't have access to

RESOLVED FIXED in Bugzilla 2.22

Status

()

Bugzilla
User Interface
--
minor
RESOLVED FIXED
13 years ago
5 years ago

People

(Reporter: timeless, Assigned: Frédéric Buclin)

Tracking

2.17.6
Bugzilla 2.22
Dependency tree / graph
Bug Flags:
approval +
blocking2.22 +

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
Access Denied
	  	
You do not have the permissions necessary to access that product.

--
That's kinda funny, since I can load:
https://bugzilla.mozilla.org/editcomponents.cgi?product=Talkback and read the
list there.
(Assignee)

Updated

13 years ago
Assignee: myk → LpSolit
OS: Windows XP → All
Hardware: PC → All
(Assignee)

Comment 1

13 years ago
Created attachment 172159 [details] [diff] [review]
allow users in the editcomponents group to view all products, v1
Attachment #172159 - Flags: review?
(Assignee)

Updated

13 years ago
Status: NEW → ASSIGNED

Updated

13 years ago
Attachment #172159 - Flags: review? → review+
(Assignee)

Updated

13 years ago
Flags: approval?
Target Milestone: --- → Bugzilla 2.20
The correct fix for this situation is to prevent the person with editcomponents
from being able to see/edit products that they don't have access to in
editproducts.cgi.  Or better yet, a product-level editcomponents priv.

There are things on b.m.o that timeless shouldn't be able to see (despite his
ability to know where the places are that he can't get to)

I'm not outright WONTFIXing this, because it might make sense for the global
editcomponents priv once we have product-level editcomponents that we can hand
out.  But there's no way I'm going to allow this to land prior to that.
Flags: approval? → approval-
Target Milestone: Bugzilla 2.20 → Future
(Reporter)

Comment 3

13 years ago
i don't see the problem, when you rework editcomponents to be per product, you'd
just rework one more cgi. either the priv disappears globally in which case you
remove it from one more script, or it's supplemented by a new permission which
is per product and would need to be applied to this script too in about the same
place as the current bit. the fact is that this really only applies to me anyway
:), and it's really just a convenience, i can just as easily get the info i want
from editcomponents.
ok, we discussed this on IRC...  we're going to fix editcomponents so unless
you're a member of group 'admin', 'editcomponents' only lets you edit products
you can otherwise see anyway.
Flags: approval-
Target Milestone: Future → Bugzilla 2.20
Comment on attachment 172159 [details] [diff] [review]
allow users in the editcomponents group to view all products, v1

review- per previous discussion
Attachment #172159 - Flags: review-
(Assignee)

Updated

13 years ago
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Summary: editcomponents priv should clobber groupset for describecomponents → editcomponents priv allows you to see/edit products you don't have access to
*** Bug 294604 has been marked as a duplicate of this bug. ***

Comment 7

13 years ago
Is there any chance that this fix can also land on 2.18.2? 
For us it would be quite important that 'admins' of a product can edit all
aspects of their own product but not those of all others.

I would even see that as a security-blocker...
(Assignee)

Updated

12 years ago
Depends on: 306265
(Assignee)

Updated

12 years ago
Depends on: 293524, 301743
(Assignee)

Comment 8

12 years ago
I won't backport this patch for 2.18 or even 2.20 as it implies a lot of new
code and files which do not exist for earlier versions, mainly Product.pm.

Note to self: when bug 293524 is fixed, the single remaining place to fix will
be editflagtypes.cgi (the list of products available for flag inclusions and
exclusions).
(Assignee)

Comment 9

12 years ago
(In reply to comment #4)
> ok, we discussed this on IRC...  we're going to fix editcomponents so unless
> you're a member of group 'admin', 'editcomponents' only lets you edit products
> you can otherwise see anyway.

editcomponents.cgi is not the only one file involved in the discussion.
editversions.cgi, editmilestones.cgi, editproducts.cgi and
editclassifications.cgi should also be considered.

But I'm not sure hiding products I'm not allowed to see is the right solution as
I could create a product which has the same name as an existing product (for
editproducts.cgi). Better would be to display product names, but forbid to
edit/get any information on them. comments?
How about if we only allow admins to create new products, or add a separate priv for that?  And then not let someone who can't see all products create new ones?

What we really need here is product-specific admin rights, but that's definitely a new feature.
(Assignee)

Comment 11

12 years ago
*** Bug 315068 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

12 years ago
Flags: blocking2.22?

Comment 12

12 years ago
Bug #315068 

What I had in mind, was that a "global" admin or even "(global) Edit component" right was used to create the product initially. Then a "local" Edit component right was granted to one of the persons, which is member of the current product.

Then they will be able to maintain their own product without the need of any global admin rights and they will not be able to access any products that they dont have permission to currently.
(Reporter)

Comment 13

12 years ago
Again, at bmo i'm likely to be allowed to create new products, so your restriction is going ot hurt things a lot more than it's going ot help. do it the other way.
(Assignee)

Comment 14

12 years ago
Created attachment 203817 [details] [diff] [review]
patch, v2

Only allows the user to edit properties of a product (including its versions, milestones and components) he is allowed to see. Per discussion with justdave on IRC, the user is trustable enough to let him know if a product he is not allowed to edit exists or not (because he could guess it anyway when creating or renaming a product to an existing name).

editclassifications.cgi uses 'editclassifications' privs and so doesn't need to be considered here.

And editflagtypes.cgi will be fixed separately...

(17:39:05) LpSolit: justdave: if a flag type is applied to a product you cannot see, I suppose editflagtypes.cgi should not allow you to edit/rename/delete this flag type?
(17:39:33) justdave: you know, this is really a huge can of worms
(17:39:40) LpSolit: yes I know
(17:39:41) justdave: make joel do it ;)
(17:39:44) LpSolit: :-D
(17:39:51) LpSolit: can I split this bug then?
(17:40:00) justdave: yeah, go for it
Attachment #172159 - Attachment is obsolete: true
Attachment #203817 - Flags: review?(wicked)

Comment 15

12 years ago
Please make sure that the "you cannot see all components unless you are in 'admin'" is documented somewhere. :-)
Flags: blocking2.22? → blocking2.22+
Keywords: relnote
Whiteboard: [relnote comment 15]
(Assignee)

Comment 16

12 years ago
(In reply to comment #15)
> Please make sure that the "you cannot see all components unless you are in
> 'admin'" is documented somewhere. :-)

Actually, this comment is wrong! Depending on how group inheritance is configured, you could be in the 'admin' group but not be allowed to see some products (a good example is our QA installations on landfill ;)).
Whiteboard: [relnote comment 15] → [relnote comment 16]
Attachment #203817 - Flags: review?(wicked) → review+
Flags: approval?
Flags: approval? → approval+
(Assignee)

Comment 17

12 years ago
Checking in editcomponents.cgi;
/cvsroot/mozilla/webtools/bugzilla/editcomponents.cgi,v  <--  editcomponents.cgi
new revision: 1.65; previous revision: 1.64
done
Checking in editmilestones.cgi;
/cvsroot/mozilla/webtools/bugzilla/editmilestones.cgi,v  <--  editmilestones.cgi
new revision: 1.47; previous revision: 1.46
done
Checking in editproducts.cgi;
/cvsroot/mozilla/webtools/bugzilla/editproducts.cgi,v  <--  editproducts.cgi
new revision: 1.108; previous revision: 1.107
done
Checking in editversions.cgi;
/cvsroot/mozilla/webtools/bugzilla/editversions.cgi,v  <--  editversions.cgi
new revision: 1.42; previous revision: 1.41
done
Checking in Bugzilla/User.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/User.pm,v  <--  User.pm
new revision: 1.97; previous revision: 1.96
done
Checking in template/en/default/global/user-error.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v  <--  user-error.html.tmpl
new revision: 1.143; previous revision: 1.142
done
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 18

12 years ago
Added to the Bugzilla 2.22 Release Notes in bug 322960, including data from comment 16 and the other relevant comments.
Keywords: relnote
Whiteboard: [relnote comment 16]
(Assignee)

Updated

9 years ago
Blocks: 347991
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.