Details

    • Similar Issues:

      Description

      https://github.com/jenkinsci/copyartifact-plugin/pull/26/files#r11160862

      Also you should be checking Run.ARTIFACTS, if Functions.isArtifactsPermissionEnabled(). Cf. Run.doArtifact. Note that ARTIFACTS is scoped to Run not Item so you would need to check this after computing src, not as part of canReadFrom.

      It can be enabled setting a system property hudson.security.ArtifactsPermission.
      https://wiki.jenkins-ci.org/display/JENKINS/Features+controlled+by+system+properties

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            Run.getACL delegates to Job.getACL since normally only a Job is actually configurable or capable of being granted distinct permissions, so this is normal, though you should still call the permission check on the Run in case that is overridden in the future. And I think it is correct that to copy artifacts from an upstream job, you should have READ and ARTIFACTS on it.

            Should copyartifact test run permissions only when project names are specified with variables?

            No, behavior should be consistent regardless of how the project name is specified. This hack was a side effect of the lack of authentication associated with a build and should be considered obsolete.

            Show
            jglick Jesse Glick added a comment - Run.getACL delegates to Job.getACL since normally only a Job is actually configurable or capable of being granted distinct permissions, so this is normal, though you should still call the permission check on the Run in case that is overridden in the future. And I think it is correct that to copy artifacts from an upstream job, you should have READ and ARTIFACTS on it. Should copyartifact test run permissions only when project names are specified with variables? No, behavior should be consistent regardless of how the project name is specified. This hack was a side effect of the lack of authentication associated with a build and should be considered obsolete.
            Hide
            ikedam ikedam added a comment -

            I think it is confusing configuration-time access checking for project names without variables.
            I'll disable configuration-time access checking and always perform access checking at runtime.
            Preserves backward compatibility providing a Java property to switch the bahavior.

            Show
            ikedam ikedam added a comment - I think it is confusing configuration-time access checking for project names without variables. I'll disable configuration-time access checking and always perform access checking at runtime. Preserves backward compatibility providing a Java property to switch the bahavior.
            Hide
            jglick Jesse Glick added a comment -

            Doing a configuration-time access check on a literal project name (one without variable expansions) makes sense but any failure should just be displayed as a FormValidation.warning; the real check should always be done at runtime. You would need to depend on 1.560+ and call Tasks.getAuthenticationOf so you can get the authentication outside the context of a specific build (or else check for this method using reflection and fall back to no validation).

            I would avoid introducing system properties unless there is no alternative.

            Show
            jglick Jesse Glick added a comment - Doing a configuration-time access check on a literal project name (one without variable expansions) makes sense but any failure should just be displayed as a FormValidation.warning ; the real check should always be done at runtime. You would need to depend on 1.560+ and call Tasks.getAuthenticationOf so you can get the authentication outside the context of a specific build (or else check for this method using reflection and fall back to no validation). I would avoid introducing system properties unless there is no alternative.
            Hide
            jglick Jesse Glick added a comment -

            Regarding compatibility, my suggestion is to piggyback on JENKINS-22949 so that when job authentication is not in use there is no permissions check, but when it is in use somehow then we unconditionally check ARTIFACTS.

            Show
            jglick Jesse Glick added a comment - Regarding compatibility, my suggestion is to piggyback on JENKINS-22949 so that when job authentication is not in use there is no permissions check, but when it is in use somehow then we unconditionally check ARTIFACTS .
            Hide
            ikedam ikedam added a comment -

            Fixed in copyartifact-1.44

            Show
            ikedam ikedam added a comment - Fixed in copyartifact-1.44

              People

              • Assignee:
                ikedam ikedam
                Reporter:
                ikedam ikedam
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: