408170 - Per-product editcomponents allows users to see ALL groups

Status: NEW

(Bugzilla :: Administration, task)

Description

[Gary Whitehead]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Build Identifier: 3.0.2

If we wish to allow a user to add components/versions to products he/she can see, that user then is given access to the "Edit Group Access Controls" page which lists every group in the system, including the ones this user should not have access to. Even worse, they get access to the "flags" page which lists every product and component in the system.

Reproducible: Always

Steps to Reproduce:
1. Create a user with access to a product but not to another
2. give that user editcomponents permissions
3. log in as that user, edit the visible product and go to "Edit Group Access Controls" OR log in as that user, click "flags" and view the product and component drop downs.
Actual Results:  
Products and groups the user should not be able to view were visible

Expected Results:  
only products & groups relevant to the user should be visible

Comment 1

[timeless]

https://bugzilla.mozilla.org/editproducts.cgi?action=editgroupcontrols&product=Bugzilla&classification=Server%20Software

These settings control the relationship of the groups to this product.
...
Any group having editcomponents selected allows users who are in this group to edit all aspects of this product, including components, milestones and versions.

I'm assuming you granted the global "editcomponents" bit instead of the per product editcomponents bit.

Am I wrong?

If you use the per product editcomponents bit, does this still happen?

Comment 2

[timeless]

Also, are you using strict_isolation?

fwiw, at the present time, bugzilla tells me that 4 = 1 + 1 + 1, I wonder if we consider that math "good". (As it happens, I already knew that, so it's OK.)

afaik, at the present time, groups have no concept of visibility or ownership. They have only concepts of membership, ability to grant, and currently applicable to a product/flag.

There is no useful way to say "this flag needs to maybe be available to these people for using". 

Similarly, flagtypes have no concept of owners, there are people who may mark a flag, and there are places where flags are currently applicable, but a person trusted to edit flagtypes should be able to add or remove a flagtype to an item (product/component).

If you need to hide meaning, you can make your flag and group names obscure.

i chose names like "oops" and "buried".

note: @bmo, I'm allowed to edit flag types, but I'm not allowed to edit most groups (I don't have editgroups, but i do have grant for some limited set of groups). And this distinction makes sense. Flags are essentially state annotations, anyone could have written in a comment "i'd like to do X". and anyone could write in another comment "Yes, do X". Having a relatively wide group of people who define "X"s makes sense. It's also a good thing that I can make a flag that says "only drivers can grant approval" even though I'm not a driver.

Flags are a form of bookkeeping, it's a thing you ask a secretary to do. You must trust the secretaries not to gossip (disclose names of groups), you don't necessarily invite the secretaries into some rooms for certain meetings (be members of the groups), but the secretaries will probably coordinate/schedule the meetings (create flag types).

OTOH, the number of people who create/change/destroy groups should be much smaller, and they should be asked to do work much less frequently (we change flags a couple of times a month, and groups maybe a couple of times a year).

Comment 3

[Gary Whitehead]

I was using the global "editcomponents" as you deduced, yes. I've backed that out now and have created a new group, put my user in it, given it an "editcomponents" tick in the relevant product and now that user no longer has access to the "flags" page so that's the main one solved, many thanks for that.

The "Edit Group Access Controls" page is still available to him under his project though and it unfortunately lists all my groups which currently have the same names as the products. As a workaround, I have renamed them all to Group1/Group2/etc. as you suggest so at least I don't have my customers knowing about each others new developments now.

Comment 4

[Gary Whitehead]

Yes, I'm using strict_isolation

Comment 5

[Max Kanat-Alexander]

I think what we'll have to do is add a per-product editgroups permission. This seems like an important enough (and common-enough) scenario to justify it. Since that's an enhancement, it would only go into the 3.2 branch, not the 3.0 branch.

Comment 6

[timeless]

see also bug 332473, bug 332474, and bug 346155
also, are you using usevisibilitygroups?

Comment 7

[Gary Whitehead]

Yes, I am using usevisibilitygroups.

The realworld situation here is that, as a computer services company in a fairly vertical market, we find ourselves doing work for companies that are competitors to each other. Allowing them all on the same bugzilla installation works fine until we wish to allow one of them to be able to edit a product of their own (we're doing a joint-effort project). This means that they can now see all the other groups as described above, giving them some indication of the other projects we're doing due simply to the group names.

Whether this situation is common enough to justify increasing the complexity of bugzilla by adding further features is debatable. The fix that suggests itself to me is to remove the "Edit Group Access Controls" facility completely for someone who only has "EditComponents" access to a particular product. Not sure how that fits in with the big picture though.

For info, I think the options available to someone in our situation are:

1. Rename all the groups to something cryptic that doesn't indicate the projects they are associated with.
2. Create a separate bugzilla installation for just this product.

I have done the former but this has made the admin of our existing installation just that little bit more complicated and so I am currently leaning towards the latter.

Comment 8

[timeless]

that definitely won't work.

you most certainly need to allow people who are configuring a product to have edit group access controls.

i'm not saying this isn't necessary. it's definitely complicated, however I'm fairly certain I'd support the request (possibly even implementing it, although hopefully someone else, like you would do that).

the steps required to make this work are:
1. groups need to have more than "system"/"user"/"use for bugs".
2. products need to have a way to specify per product editflagtypes (using per product editcomponents is fine).
2. flags should only be editable by people with permission to edit all products it currently affects.

Comment 9

[Frédéric Buclin]

(In reply to comment #5)
> I think what we'll have to do is add a per-product editgroups permission.

Not sure that's the most important part here. If usevisibilitygroups is on, then we should only display groups the user can see, else display all groups as we do now. We may obfuscate other group names already set for this product so that the user knows some groups he cannot see are used for this product.

About editflagtypes.cgi, this page requires global editcomponents privs, not per-product ones, so the current behavior is expected as only sysadmins should/may have such privs.

Comment 10

[Frédéric Buclin]

We shouldn't mess 3.2 now that we are frozen.

Comment 11

[Nick]

In our bugzilla installation we are having this problem too. Apart from that usevisibilitygroups is not working in this situation, maybe another per-product group control permission can be added named "maintaincomponent" which allows the users in that group to only edit the following information": description, url, votes, components, versions and milestones. But not edit the group access controls, close bug entry or rename the product.

Just an idea, but I guess this can help admins in larger installations.

Comment 12

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.