-
Bug
-
Resolution: Fixed
-
Critical
-
None
-
CloudBees Core 2.150.2.3 w/ CAP enabled
artifact-manager-s3 plugin v1.1
-
-
1.2
Users without Overall/Administrator are not able to view artifacts in the UI or download them. In the Jenkins log, I'm seeing the following traceback (full details in attachment):
"February 6th 2019, 17:01:48.696","Feb 06, 2019 5:01:48 PM hudson.model.Run getArtifactsUpTo" "February 6th 2019, 17:01:48.696","WARNING: null" "February 6th 2019, 17:01:48.697"," at io.jenkins.plugins.artifact_manager_jclouds.JCloudsVirtualFile.run(JCloudsVirtualFile.java:328)" "February 6th 2019, 17:01:48.697","java.io.IOException: hudson.security.AccessDeniedException2: mat007 is missing the Overall/Administer permission" "February 6th 2019, 17:01:48.698"," at hudson.model.Run.getArtifactsUpTo(Run.java:1104)" "February 6th 2019, 17:01:48.698"," at io.jenkins.blueocean.service.embedded.rest.AbstractRunImpl.getArtifactsZipFile(AbstractRunImpl.java:278)" "February 6th 2019, 17:01:48.698"," at hudson.model.Run.getHasArtifacts(Run.java:1121)" "February 6th 2019, 17:01:48.699"," at io.jenkins.blueocean.commons.stapler.export.ExportInterceptor$1.getValue(ExportInterceptor.java:46)" "February 6th 2019, 17:01:48.699"," at io.jenkins.blueocean.commons.stapler.export.MethodProperty.getValue(MethodProperty.java:72)" ... snip ...
[JENKINS-56004] Overall/Administrator required to view s3 artifacts?
FWIW, I also just noticed that the traceback log output is not guaranteed to be in-order either (for a given timestamp)...
psftw not sure what that means. Maybe something related to the logging system used in CloudBees Core. If so, please report it through vendor channels, so this issue can be focused on the inappropriate AccessDeniedException2.
jglick The log record ordering issue is an artifact of our logging system, nothing to do with Jenkins. The effect is that some records in the attached artifacts.log may not be in exactly the same order as what Jenkins emitted.
psftw understood. Does not matter in this case as I can reproduce what appears to be an identical issue in a functional test anyway.
Just upgraded to aws-global-configuration:1.2 and can confirm the fix in my environment. Thank you!
The critical part of the stack is what was snipped out: the fact CredentialsAwsGlobalConfiguration.getCredentials is checking ADMINISTER.