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

          [JENKINS-22460] Support artifacts permission

          Jesse Glick added a comment -

          Marking as a bug since the current behavior is actually a security vulnerability: the plugin can be used to bypass an intentionally restricted permission.

          Jesse Glick added a comment - Marking as a bug since the current behavior is actually a security vulnerability: the plugin can be used to bypass an intentionally restricted permission.

          ikedam added a comment -

          The current (Jenkins 1.567, matrix-project-plugin 1.2, maven-plugin 2.3) feature of artifacts permission in Jenkins:

          • When launching Jenkins with "-Dhudson.security.ArtifactsPermission=true", Run.Artifacts is shown in "Matrix-based security" and " Project-based Matrix Authorization Strategy" in the Global Security Configuration page and "Enable project-based security" in the project configuration page.
          • Jenkins seems not support per run ACL.
            • Run.getACL() returns getParent().getACL()
            • none of subclasses of Run does not override getACL()
              • hudson.model.AbstractBuild
              • hudson.model.Build
              • hudson.model.FreeStyleBuild
              • hudson.matrix.MatrixBuild
              • hudson.matrix.MatrixRun
              • hudson.maven.AbstractMavenBuild
              • hudson.maven.MavenBuild
              • hudson.maven.MavenModuleSetBuild

          ikedam added a comment - The current (Jenkins 1.567, matrix-project-plugin 1.2, maven-plugin 2.3) feature of artifacts permission in Jenkins: When launching Jenkins with "-Dhudson.security.ArtifactsPermission=true", Run.Artifacts is shown in "Matrix-based security" and " Project-based Matrix Authorization Strategy" in the Global Security Configuration page and "Enable project-based security" in the project configuration page. Jenkins seems not support per run ACL. Run.getACL() returns getParent().getACL() none of subclasses of Run does not override getACL() hudson.model.AbstractBuild hudson.model.Build hudson.model.FreeStyleBuild hudson.matrix.MatrixBuild hudson.matrix.MatrixRun hudson.maven.AbstractMavenBuild hudson.maven.MavenBuild hudson.maven.MavenModuleSetBuild

          ikedam added a comment -

          Should I test Item.READ also for Run ?

          ikedam added a comment - Should I test Item.READ also for Run ?

          ikedam added a comment -

          There are following problems to introduce this feature:

          • Backward compatibility:
            • Many users will face problems in copying artifacts introducing this feature (Especially if copyartifact will test Item.READ against Run).
            • Should copyartifact introduce a Java property to disable this feature?
          • Should copyartifact test run permissions only when project names are specified with variables?
            • Copyartifact tests project permissions at runtime only when project names are specified with variables. Should it be applied also for run permissions?
            • If tests them also when project names is specified without variables, more users will face problems.

          ikedam added a comment - There are following problems to introduce this feature: Backward compatibility: Many users will face problems in copying artifacts introducing this feature (Especially if copyartifact will test Item.READ against Run ). Should copyartifact introduce a Java property to disable this feature? Should copyartifact test run permissions only when project names are specified with variables? Copyartifact tests project permissions at runtime only when project names are specified with variables. Should it be applied also for run permissions? If tests them also when project names is specified without variables, more users will face problems.

          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.

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

          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.

          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.

          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.

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

          Fixed in copyartifact-1.44

          ikedam added a comment - Fixed in copyartifact-1.44

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

              Created:
              Updated:
              Resolved: