Details
-
Bug
-
Resolution: Fixed
-
Medium
-
4.0, 6.2.5
-
4
-
Description
For the same reason as JRA-33035, if a permission is granted to Customfield, then the permission rules are broken.
In fact, as soon as a Permission is granted to a Customfield (User or Group), if the Permission is evaluated against Project and not Issue, the permission is always True.
User and Group customfields are evaluating the Permission on Project as follow :
protected boolean hasProjectPermission(User user, boolean issueCreation, Project project) { return !issueCreation; }
I have identified potential issue in following Permission Check :
- ASSIGNABLE_USER in AssigneeSystemField.validateParams() :
ComponentAccessor.getPermissionManager().hasPermission(Permissions.ASSIGNABLE_USER, issue.getProjectObject(), assigneeUser))
- CREATE_ATTACHMENT in DefaultAttachmentService.canCreateAttachments :
permissionManager.hasPermission(Permissions.CREATE_ATTACHMENT, project, jiraServiceContext.getLoggedInApplicationUser())
- CREATE_ATTACHMENT in DefaultCommentService.hasPermissionToCreate() :
boolean hasPerm = (issue.getProjectObject() == null) ? permissionManager.hasPermission(Permissions.COMMENT_ISSUE, issue, user) : permissionManager.hasPermission(Permissions.COMMENT_ISSUE, issue.getProjectObject(), user);
- VIEW_VOTERS_AND_WATCHERS in DefaultVoteService.viewVoters() :
permissionManager.hasPermission(Permissions.VIEW_VOTERS_AND_WATCHERS, issue.getProjectObject(), remoteUser)
- MOVE_ISSUE in IssueTypeSystemField.getEditHtml() :
getPermissionManager().hasPermission(Permissions.MOVE_ISSUE, issue.getProjectObject(), getAuthenticationContext().getUser())
- VIEW_VOTERS_AND_WATCHERS in ViewVoters.doDefault(), ViewVoters.doAddVote(), ViewVoters.doRemoveVote(), :
permissionManager.hasPermission(Permissions.VIEW_VOTERS_AND_WATCHERS, getProject(), getLoggedInUser())
- COMMENT_ISSUE in WorkflowTransitionUtilImpl.validateComment() :
permissionManager.hasPermission(Permissions.COMMENT_ISSUE, getProject(), getRemoteApplicationUser())
There are many other similar cases where the BROWSE permission is evaluated only against Project and not Issue. But this permission issue can be resolved with Issue Security Levels.
If it is not decided to correct similar cases, it will be needed for final Administrator users, to let them know which permissions is only evaluated on Project and which are evaluated against Issue.
In all cases, for created Issues, the AbstractIssueFieldSecurityType (UserCF , GroupCF) should not return True, but should evaluate the permission against the Issue, or simply ignored, if there is no sense to evaluate the permission against the issue.
The error seems to present since UserCF and GroupCF exist as SecurityType (JIRA 4.0 or before).
Attachments
Issue Links
- causes
-
JRASERVER-40124 Assignable Users are no longer assignable for an issue if they don't belong to the Issue Security Level permissions
- Closed
- incorporates
-
JRASERVER-33035 Workflow properties on JIRA permission allow unassignable users to be assigned
- Closed
-
JRASERVER-37117 Grant "Browse Project" permission to "User Custom Field Value" makes project visible to all users
- Long Term Backlog