Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-22460

Support artifacts permission

    XMLWordPrintable

Details

    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

            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.

            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.
            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.

            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.
            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.

            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.
            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.

            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 .
            ikedam ikedam added a comment -

            Fixed in copyartifact-1.44

            ikedam ikedam added a comment - Fixed in copyartifact-1.44

            People

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

              Dates

                Created:
                Updated:
                Resolved: