View Issue Details

WikiRelated ChangesetsJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0013140mantisbtauthenticationpublic2011-07-13 03:312014-09-23 18:05
Reportertoddpw Assigned Todhx  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version1.2.5 
Target Version1.2.8Fixed in Version1.2.8 
Summary0013140: cloning an issue uses incorrect permissions during actual submit operation
Description

It appears that when you clone an issue, you have the correct access level for that issue's project UNTIL you submit the issue, at which point the currently selected project's access level plays a role when it should not. However it only happens when cloning an issue you did not originally report.

I used severity "minor" because there is a workaround -- switch project to the issue's project before attempting to clone it. But it breaks the universal expectation that my users have -- that if a specific issue is being operated on, you always inherit access levels from the project containing that issue, rather than taking it from the current project, which is what appears to be happening.

Steps To Reproduce

Fresh 1.2.5 install.

Create two users, a Developer and an Updater.
Create a private project.
(Actually create a couple more projects so you can see the project selector.)
Add both users to the private project AS MANAGERS.
Login as Developer, select the private project, and create an issue.
Login as Updater, select All Projects, and attempt to clone that issue. It fails with ACCESS DENIED error #13. Also note that your access level was Manager while editing the cloned issue, but in the error screen your access level is back to your global access of Updater.

As Updater, Select the private project, create an issue. Then select All Projects, and attempt to clone that issue. It succeeds, apparently because you are cloning your own issue.

Create a public project and attach the private project as a subproject of it. Retry the above cloning tests with the public parent project instead of All Projects -- the results are the same whether you select All Projects or the parent project.

Additional Information

I suspect that the access level of the Developer user doesn't matter so much, ie. it could be another Updater but just has to be different so the cloning user is not the original reporter of the issue he is trying to clone.

Tagspatch
Attached Files
0013140.patch.txt (1,013 bytes)    
*** bug_report.php.orig	Wed Jul 13 04:06:43 2011
--- bug_report.php	Wed Jul 13 04:15:15 2011
***************
*** 34,39 ****
--- 34,55 ----
  
  	form_security_validate( 'bug_report' );
  
+ /* 0013140 cloned bug gets access of its project, not current project */
+ 	$f_master_bug_id = gpc_get_int( 'm_id', 0 );
+ 	if ( $f_master_bug_id > 0 ) {
+ 		bug_ensure_exists( $f_master_bug_id );
+ 		if ( bug_is_readonly( $f_master_bug_id ) ) {
+ 			error_parameters( $f_master_bug_id );
+ 			trigger_error( ERROR_BUG_READ_ONLY_ACTION_DENIED, ERROR );
+ 		}
+ 		$t_bug = bug_get( $f_master_bug_id, true );
+ 		access_ensure_bug_level( config_get( 'update_bug_threshold', null, $t_bug->project_id ), $f_master_bug_id );
+ 		if( $t_bug->project_id != helper_get_current_project() ) {
+ 			$g_project_override = $t_bug->project_id;
+ 		}
+ 	}
+ /* 0013140 cloned bug gets access of its project, not current project */
+ 
  	access_ensure_project_level( config_get('report_bug_threshold' ) );
  
  	$t_bug_data = new BugData;
0013140.patch.txt (1,013 bytes)   
0013140.patch2.txt (1,990 bytes)    
*** bug_report.php.orig	Wed Jul 13 04:06:43 2011
--- bug_report.php	Wed Jul 13 05:12:25 2011
***************
*** 34,39 ****
--- 34,55 ----
  
  	form_security_validate( 'bug_report' );
  
+ /* 0013140 cloned bug gets access of its project, not current project */
+ 	$f_master_bug_id = gpc_get_int( 'm_id', 0 );
+ 	if ( $f_master_bug_id > 0 ) {
+ 		bug_ensure_exists( $f_master_bug_id );
+ 		if ( bug_is_readonly( $f_master_bug_id ) ) {
+ 			error_parameters( $f_master_bug_id );
+ 			trigger_error( ERROR_BUG_READ_ONLY_ACTION_DENIED, ERROR );
+ 		}
+ 		$t_bug = bug_get( $f_master_bug_id, true );
+ 		access_ensure_bug_level( config_get( 'update_bug_threshold', null, null, $t_bug->project_id ), $f_master_bug_id );
+ 		if( $t_bug->project_id != helper_get_current_project() ) {
+ 			$g_project_override = $t_bug->project_id;
+ 		}
+ 	}
+ /* 0013140 cloned bug gets access of its project, not current project */
+ 
  	access_ensure_project_level( config_get('report_bug_threshold' ) );
  
  	$t_bug_data = new BugData;
*** bug_report_page.php.orig	Wed Jul 13 05:11:07 2011
--- bug_report_page.php	Wed Jul 13 05:11:43 2011
***************
*** 56,62 ****
  		$t_bug = bug_get( $f_master_bug_id, true );
  
  		# the user can at least update the master bug (needed to add the relationship)...
! 		access_ensure_bug_level( config_get( 'update_bug_threshold', null, $t_bug->project_id ), $f_master_bug_id );
  
  		#@@@ (thraxisp) Note that the master bug is cloned into the same project as the master, independent of
  		#       what the current project is set to.
--- 56,62 ----
  		$t_bug = bug_get( $f_master_bug_id, true );
  
  		# the user can at least update the master bug (needed to add the relationship)...
! 		access_ensure_bug_level( config_get( 'update_bug_threshold', null, null, $t_bug->project_id ), $f_master_bug_id );
  
  		#@@@ (thraxisp) Note that the master bug is cloned into the same project as the master, independent of
  		#       what the current project is set to.
0013140.patch2.txt (1,990 bytes)   

Relationships

related to 0015721 closedgrangeway Functionality to consider porting to master-2.0.x 

Activities

toddpw

toddpw

2011-07-13 04:21

reporter   ~0029155

This bug appears to have been fixed by thraxisp in bug_report_page.php, but not bug_report.php.

See the attached file for a context diff that ports the fix over.

With this fix, the steps to reproduce now get the desired result.
toddpw

toddpw

2011-07-13 05:18

reporter   ~0029157

Actually while investigating another bug I noticed that the arguments passed to config_get are incorrect and omit 'p_default'. There is another instance of this in the stored query use threshold check which I will report separately.

So please use patch2 instead of the previous attachment.
dhx

dhx

2011-09-05 08:29

reporter   ~0029640

Thanks Todd! Great report and great patch!

I have committed your patch to master-1.2.x and master branches with an additional bug fix that also sets the project override based on the "project_id" parameter to the script that is passed in from bug_report_page.php
grangeway

grangeway

2013-04-05 17:57

reporter   ~0036408

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch

Related Changesets

MantisBT: master b08e9c16

2011-09-05 01:15

dhx


Details Diff		 Fix 0013140: Incorrect permissions check during bug reporting and cloning

Todd Whitesel reported an issue with incorrect permissions checks being
performed when cloning issues. The steps to reproduce this bug were
provided by Todd:

------
Fresh 1.2.5 install.

Create two users, a Developer and an Updater.
Create a private project.
(Actually create a couple more projects so you can see the project
selector.)
Add both users to the private project AS MANAGERS.
Login as Developer, select the private project, and create an issue.
Login as Updater, select All Projects, and attempt to clone that issue.
It fails with ACCESS DENIED error #13. Also note that your access level
was Manager while editing the cloned issue, but in the error screen your
access level is back to your global access of Updater.

As Updater, Select the private project, create an issue. Then select All
Projects, and attempt to clone that issue. It succeeds, apparently
because you are cloning your own issue.

Create a public project and attach the private project as a subproject
of it. Retry the above cloning tests with the public parent project
instead of All Projects -- the results are the same whether you select
All Projects or the parent project.
------

The problem was that the current project (from the project selector
dropdown) was used as the basis for config_get calls, thus leading to
incorrect permissions and settings being used within bug_report.php. We
need to instead switch (temporarily) the current project to either the
master issue (when cloning) or the specified project_id (when creating a
new issue via bug_report_page.php).

Thanks again to Todd for the discovery and debugging of this problem, the
detailed bug report and initial patch (that has been extended to resolve
the second project_id issue from bug_report_page.php).

Conflicts:
bug_report.php		 Affected Issues
0013140
mod - bug_report.php Diff File

MantisBT: master-1.2.x 9be5d99a

2011-09-05 01:15

dhx


Details Diff		 Fix 0013140: Incorrect permissions check during bug reporting and cloning

Todd Whitesel reported an issue with incorrect permissions checks being
performed when cloning issues. The steps to reproduce this bug were
provided by Todd:

------
Fresh 1.2.5 install.

Create two users, a Developer and an Updater.
Create a private project.
(Actually create a couple more projects so you can see the project
selector.)
Add both users to the private project AS MANAGERS.
Login as Developer, select the private project, and create an issue.
Login as Updater, select All Projects, and attempt to clone that issue.
It fails with ACCESS DENIED error #13. Also note that your access level
was Manager while editing the cloned issue, but in the error screen your
access level is back to your global access of Updater.

As Updater, Select the private project, create an issue. Then select All
Projects, and attempt to clone that issue. It succeeds, apparently
because you are cloning your own issue.

Create a public project and attach the private project as a subproject
of it. Retry the above cloning tests with the public parent project
instead of All Projects -- the results are the same whether you select
All Projects or the parent project.
------

The problem was that the current project (from the project selector
dropdown) was used as the basis for config_get calls, thus leading to
incorrect permissions and settings being used within bug_report.php. We
need to instead switch (temporarily) the current project to either the
master issue (when cloning) or the specified project_id (when creating a
new issue via bug_report_page.php).

Thanks again to Todd for the discovery and debugging of this problem, the
detailed bug report and initial patch (that has been extended to resolve
the second project_id issue from bug_report_page.php).		 Affected Issues
0013140
mod - bug_report.php Diff File