0012361: Can see private bug in MyView / ViewIssues but then 'access denied' when I view it - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0012361	mantisbt	sub-projects	public	2010-09-16 09:37	2014-09-23 18:05

Reporter	toddpw	Assigned To	dhx
Priority	normal	Severity	major	Reproducibility	always
Status	closed	Resolution	fixed
Product Version	1.2.2
Target Version	1.2.8	Fixed in Version	1.2.8

Summary	0012361: Can see private bug in MyView / ViewIssues but then 'access denied' when I view it
Description	In the My View / View Issues screens, private bugs in public projects (and probably private projects too) appear to ignore the private_bug_threshold value of their project unless you select it. When some projects have tighter security on viewing private bugs than others, this creates a situation where a user who should not be able to see a bug can still discover its existence in My View and View Issues. Viewing it fails with 'access denied', but if the summary had confidential information in it then the security leak has already happened. I don't consider giving All Projects the tighter security to be a usable workaround, because then you can't find bugs in the projects that use normal security for private bugs, until you select one of them, but then you can only see the subproject hierarchy you just went into.
Steps To Reproduce	On a fresh 1.2.2 install try this: Create a public project. In the project, edit thresholds so that you need manager to view private bugs. Submit a private bug to that project. Login as a different user with global access of developer. View All Projects. You can see the bug in MyView / ViewIssues but then when you click on it you get an Access Denied screen. If you select the bug's project, then it correctly disappears.
Additional Information	Workaround... in each project that I wanted tighter security, I am either taking it private or giving it a private subproject and trying to keep the user list small.
Tags	patch
Attached Files	0012361.patch.txt (1,050 bytes) * core/filter_api.php.orig Wed Jul 13 04:49:27 2011 --- core/filter_api.php Wed Jul 13 05:08:27 2011 *********** * 1177,1184 **** // this array is populated with project ids that the current user has full access to. $t_private_and_public_project_ids = array(); - $t_access_required_to_view_private_bugs = config_get( 'private_bug_threshold' ); foreach( $t_project_ids as $t_pid ) { if( access_has_project_level( $t_access_required_to_view_private_bugs, $t_pid, $t_user_id ) ) { $t_private_and_public_project_ids[] = $t_pid; } else { --- 1177,1184 ---- // this array is populated with project ids that the current user has full access to. $t_private_and_public_project_ids = array(); foreach( $t_project_ids as $t_pid ) { + $t_access_required_to_view_private_bugs = config_get( 'private_bug_threshold', null, null, $t_pid ); if( access_has_project_level( $t_access_required_to_view_private_bugs, $t_pid, $t_user_id ) ) { $t_private_and_public_project_ids[] = $t_pid; } else { 0012361.patch.txt (1,050 bytes)

jreese 2010-09-16 13:23 reporter ~0026740	Can you confirm for me if this happens if you have the public project selected as your current project? Does it also happen if you have a parent project selected, or only for All Projects?

toddpw 2011-07-13 02:27 reporter ~0029154	Found some time to look at this again and tried it on a fresh 1.2.5 install. The Access Denied still occurs if the steps to reproduce are followed. When the Developer user selects the public project as his current project, the submitted private bug correctly disappears from My View / View Issues. I created a 2nd public project and made it a parent of the original public project. The private bug only disappears when its project is selected; the parent project gives the same behavior as All Projects (can see bug but opening it gives an Access Denied response page).

toddpw 2011-07-13 05:35 reporter ~0029158	Found the problem. Context diff attached. In core/filter_api.php:filter_get_bug_rows() there is a check for each project the user can see, to decide if he can see private issues, or only public issues. This check correctly gets the user's access level for each project but then tests it against the GLOBAL threshold for seeing private issues. The attached diff computes the threshold separately for each project and fixes the problem reported above.

dhx 2011-09-05 08:39 reporter ~0029641	Thanks Todd, another very good report and patch. I've committed it to the master-1.2.x and master branches ready for the next release. Notice how I'm going through every report you've created and resolving them quickly... because I know the bug report quality is extremely high :) Apologies for the amount of time it has taken to respond to your reports and commit patches.

grangeway 2013-04-05 17:57 reporter ~0036409	Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

MantisBT: master 94e68102 2011-09-05 01:34 toddpw Details Diff	Fix 0012361: Private bug visibility leak in my_view/view_all_bug_page In the My View / View Issues screens, private bugs in public projects (and probably private projects too) appear to ignore the private_bug_threshold value of their project unless you select it. When some projects have tighter security on viewing private bugs than others, this creates a situation where a user who should not be able to see a bug can still discover its existence in My View and View Issues. Viewing it fails with 'access denied', but if the summary had confidential information in it then the security leak has already happened. I don't consider giving All Projects the tighter security to be a usable workaround, because then you can't find bugs in the projects that use normal security for private bugs, until you select one of them, but then you can only see the subproject hierarchy you just went into. Steps to reproduce: ------ On a fresh 1.2.2 install try this: Create a public project. In the project, edit thresholds so that you need manager to view private bugs. Submit a private bug to that project. Login as a different user with global access of developer. View All Projects. You can see the bug in MyView / ViewIssues but then when you click on it you get an Access Denied screen. If you select the bug's project, then it correctly disappears. ------ Signed-off-by: David Hicks <d@hx.id.au>		Affected Issues 0012361
	mod - core/filter_api.php		Diff File
MantisBT: master-1.2.x cb74408f 2011-09-05 01:34 toddpw Details Diff	Fix 0012361: Private bug visibility leak in my_view/view_all_bug_page In the My View / View Issues screens, private bugs in public projects (and probably private projects too) appear to ignore the private_bug_threshold value of their project unless you select it. When some projects have tighter security on viewing private bugs than others, this creates a situation where a user who should not be able to see a bug can still discover its existence in My View and View Issues. Viewing it fails with 'access denied', but if the summary had confidential information in it then the security leak has already happened. I don't consider giving All Projects the tighter security to be a usable workaround, because then you can't find bugs in the projects that use normal security for private bugs, until you select one of them, but then you can only see the subproject hierarchy you just went into. Steps to reproduce: ------ On a fresh 1.2.2 install try this: Create a public project. In the project, edit thresholds so that you need manager to view private bugs. Submit a private bug to that project. Login as a different user with global access of developer. View All Projects. You can see the bug in MyView / ViewIssues but then when you click on it you get an Access Denied screen. If you select the bug's project, then it correctly disappears. ------ Signed-off-by: David Hicks <d@hx.id.au>		Affected Issues 0012361
	mod - core/filter_api.php		Diff File