Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-38407

Permissions based on Customfields do not work in all cases

    XMLWordPrintable

Details

    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

          Activity

            People

              ohernandez@atlassian.com Oswaldo Hernandez (Inactive)
              5d77aaa81033 Vincent Thoulé
              Votes:
              2 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: