Group Name Guessing Disclosure Policy

Max Kanat-Alexander mkanat at bugzilla.org
Tue Jul 20 20:44:09 UTC 2010


On 07/20/2010 12:48 PM, Marc Schumann wrote:
> Yeah, editwhines.cgi is a good example. I'd expect it to be pretty
> much $user->can_see_group like -- isn't it? It eludes me how the logic
> can be all that difficult...

	The conditions under which a user can see a group name are ill-defined
and very complex. The conditions I can think of off the top of my head are:

	A user can see a group's name if they can enter a bug in any product
where that group is mandatory, shown, or default for them.

	A user can see a group's name if any bug that they have access to has
OtherControl for that group, even if they are not in the group.

	A user can see a group's name if they have been CC'ed on or are the
reporter of a bug that is restricted to a group that they normally
cannot see.

	A user can see a group's name if they have editcomponents for any product.

	A user can see a group's name if they are in it directly, by
inheritance, or by regex.

	A user can see a group's name if they have global editcomponents,
editusers, creategroups, or are in the admin group.

	A user can see a group's name if any user with that group's icon has
ever commented on any bug they can see. (Or it might be only the group
description--I'm not sure, but that's just as bad.)

	In the future, these conditions will expand and likely become more
complex. For example, depending on how we do flag requestee
autocomplete, it's possible that users will be able to see the name of
any group that is in the grantgroup of any flag on any bug they can see.

	In customized installations, there are likely to be additional
conditions under which group names can be seen. Customizers (and future
Bugzilla developers) are unlikely to remember or understand these extra
conditions.

	So, instead of creating a performance-draining and extremely complex
centralized method for determining all of the above, I figured I'd just
modify our policy on the subject.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.



More information about the developers mailing list