323870 - Should limit users in assignee/cc/qa list to those permitted to have that role

Status: NEW

(Bugzilla :: Administration, task, P3)

Description

[Alexander Bogush]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; InfoPath.1; .NET CLR 1.1.4322)
Build Identifier: any

Assignee and CC list always contains all bugzilla users - regardless of their permissions to certain product. 
It is security breach - if product is Mandatory for specific group, the entire workflow of this product should seize only users of this group.

Reproducible: Always

Steps to Reproduce:
1. create product and group which is mandatory for it.
2. add one user to this group
3. try to submit bug under this user - he/she will see all bugzilla users instead of only himself as possible assignee.

Actual Results:  
I can see all bugzilla users in assignee list, even those that are not in this product's group.


Users which have no permissions to certain product should be unvisible in this product's workflow.

Comment 1

[Frédéric Buclin]

Not a security bug.

First, you can restrict the user list to users you are allowed to see by turning on the 'usevisibilitygroup' parameter. This will not restrict the list to those who are in the mandatory group for the given product, but at least this will restrict the list to those you are "allowed to know" they exist.

Secondly, if you want to prevent these users to be added as assignee or in the CC list, you can turn on both the 'strict_isolation' parameter and the 'canedit' bit on the "Group Controls" page for this product. This way, only users who are in the mandatory group *and* whom you know they exist can be added to the bug. The 'strict_isolation' parameter has been implemented in 2.21 and will be available in Bugzilla 2.22rc1 to be released in two weeks.


The reason I keep this bug open is that the 'usemenuforusers' parameter, when turned on, as well as user matching in general, should only display users who can edit the product when both the 'canedit' bit and the 'strict_isolation' parameter are turned on, else the list offers you to add some users to the list who will be rejected later:

 User '[e-mail]' is not able to edit the Product for bug '420'. 

joel, this would involve to update User::match() to take the 'strict_isolation' param into account. Is that something you want to do yourself?

Comment 2

[Joel Peshkin]

I agree that we should not offer the option of assigning/cc-ing/qa-ing a user who is just going to be rejected.  The only question is how to handle the wildcards.  Should we create a distinct error message for cases where a wildcard matches a user but they cannot be added to the bug?  Does the wildcard have to be less unique?

Anyway, I don't insist on implmenting this myself though I may do it.  I suggest that we get a consensus on how to handle the quesions above before beginning an implementation.

Comment 3

[Alexander Bogush]

May be I'm doing something wrong, but on Version 2.20rc2:
1) Enabled usevisibilitygroups
2) Added user - first step - user created.
On the second step having admin rights I want to add this user to number of groups from the list - bugzilla shows error "Sorry, there are visibility restrictions on certain user groups, and so you are not authorized to modify the user you specified."

If I simply skip it - anyway, all new users will be invisible for admin since their creation. 

The only workaround that I found yet is to disable usevisibilitygroups param and then enable it after user added.