• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • core

      When a user tries to download an archived artifact from a job page, they get this error:

       

      HTTP ERROR 403 Failed permission check: don-test is missing the Overall/Read permission
      
      URI:/static-files/LONG_HASH_CODE/project/3.3/20200728233035/graylog-3.3.3-SNAPSHOT-20200728233035.tgz
      STATUS:403
      MESSAGE:Failed permission check: don-test is missing the Overall/Read permission
      SERVLET:Stapler
      
      Powered by Jetty:// 9.4.27.v20200227
      

       

      The same user otherwise has full access to all jobs in Jenkins. It's only when they click on an artifact and get redirected to the Resource Root URL that this error pops up.

      Users configured as an administrator are able to download the artifact just fine. 

      If I create a custom logger on ""jenkins.security", I see:

       

      Aug 04, 2020 11:09:26 AM FINER jenkins.security.ResourceDomainFilter
      Aug 04, 2020 11:09:26 AM FINER jenkins.security.ResourceDomainFilterAccepting request to https://JENKINS-RESOURCE-ROOT-URL/static-files/LONG_HASH_CODE/project/3.3/20200728233035/graylog-3.3.3-SNAPSHOT-20200728233035.tgz from IP-ADDRESS on resource domain
      Aug 04, 2020 11:09:26 AM FINE jenkins.security.ResourceDomainRootActionPerforming a request as authentication: don-test and restOfUrl: job/Graylog-Snapshots/job/graylog2-server/job/3.3/lastSuccessfulBuild/artifact and restOfPath: /project/3.3/20200728233035/graylog-3.3.3-SNAPSHOT-20200728233035.tgz
      Aug 04, 2020 11:09:26 AM FINE jenkins.security.ResourceDomainRootAction
      Aug 04, 2020 11:09:26 AM FINE jenkins.security.ResourceDomainRootActionSuccessfully impersonated don-test
      Aug 04, 2020 11:09:26 AM FINE jenkins.security.ResourceDomainRootActionFailed permission check for resource URL accesshudson.security.AccessDeniedException2: don-test is missing the Overall/Read permission at hudson.security.ACL.checkPermission(ACL.java:79) at hudson.security.AccessControlled.checkPermission(AccessControlled.java:47) at jenkins.model.Jenkins.getTarget(Jenkins.java:4794) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:703) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:878) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:676) at jenkins.security.ResourceDomainRootAction$InternalResourceRequest.doDynamic(ResourceDomainRootAction.java:228) at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627) at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:396) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:408) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:212) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:145) at org.kohsuke.stapler.MetaClass$10.dispatch(MetaClass.java:480) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:747) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:878) at org.kohsuke.stapler.MetaClass$9.dispatch(MetaClass.java:456) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:747) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:878) at org.kohsuke.stapler.MetaClass$9.dispatch(MetaClass.java:456) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:747) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:878) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:676) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:755) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1617) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:154) at org.jenkinsci.plugins.ssegateway.Endpoint$SSEListenChannelFilter.doFilter(Endpoint.java:248) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:151) at jenkins.security.ResourceDomainFilter.doFilter(ResourceDomainFilter.java:76) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:151) at io.jenkins.blueocean.ResourceCacheControl.doFilter(ResourceCacheControl.java:134) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:151) at io.jenkins.blueocean.auth.jwt.impl.JwtAuthenticationFilter.doFilter(JwtAuthenticationFilter.java:61) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:151) at jenkins.metrics.impl.MetricsFilter.doFilter(MetricsFilter.java:125) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:151) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:59) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:151) at jenkins.telemetry.impl.UserLanguages$AcceptLanguageFilter.doFilter(UserLanguages.java:128) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:151) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:157) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:159) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:119) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:90) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:171) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:82) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604) at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604) at jenkins.security.SuspiciousRequestFilter.doFilter(SuspiciousRequestFilter.java:36) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:566) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) at org.eclipse.jetty.server.Server.handle(Server.java:500) at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383) at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938) at java.lang.Thread.run(Thread.java:748)
      

       

      I am unsure if it is a misconfiguration on my part or if it's truly a bug. I figure it it works for administrators, it can't be the nginx/proxy config. 

      I am using the Github OAuth plugin for authentication, with the "GitHub Committer Authorization Strategy". A check of the /whoAmI page shows that the user is authenticated and is part of the proper Org. 

       

       

       

          [JENKINS-63296] Failed permission check on Resource Root URL

          Donald Morton added a comment - - edited

          Update: I have fixed this by changing my Authorization strategy from 'GitHub Committer Authorization Strategy' to 'Matrix-based security' and explicitly defining permissions. No idea why that would work, as 'Overall/Read' should exist the other way, too. The users are able to view the job page, after all. 

          Donald Morton added a comment - - edited Update: I have fixed this by changing my Authorization strategy from 'GitHub Committer Authorization Strategy' to 'Matrix-based security' and explicitly defining permissions. No idea why that would work, as 'Overall/Read' should exist the other way, too. The users are able to view the job page, after all. 

          David Sargent added a comment - - edited

          I can confirm this bug and maybe bring some more clarity.
          We ran into the same issue after implementing resource root URLs,.  We are using Azure AD matrix auth and when the user is provisioned with a security group they do not get access to resources via the resource root URL.  If we add them via their account instead of a security group, it works.

          I noticed this same issue with Jenkins API keys, I had to add the user as the group would not work.  I don't know if this broke after switching to resource root URLs or not.
          For us we will be switching back to not using resource URLs and instead turning off content security policy, which is a bummer.

          David Sargent added a comment - - edited I can confirm this bug and maybe bring some more clarity. We ran into the same issue after implementing resource root URLs,.  We are using Azure AD matrix auth and when the user is provisioned with a security group they do not get access to resources via the resource root URL.  If we add them via their account instead of a security group, it works. I noticed this same issue with Jenkins API keys, I had to add the user as the group would not work.  I don't know if this broke after switching to resource root URLs or not. For us we will be switching back to not using resource URLs and instead turning off content security policy, which is a bummer.

          Lee added a comment - - edited

          I had the same issue with the GitHub Auth where any GitHub user would be allowed access to Jenkins.

          Using matrix authorization allow restricting access to just users in our teams.

          The org level restriction did not seem to work.

          from the Jenkins plugin docs

          https://plugins.jenkins.io/github-oauth/

          You can configure authorization based on GitHub users, organizations, or teams.

          • username - give permissions to a specific GitHub username.
          • organization - give permissions to every user that belongs to a specific GitHub organization.
          • organization*team - give permissions to a specific GitHub team of a GitHub organization. Notice that organization and team are separated by an asterisk (*).

          Lee added a comment - - edited I had the same issue with the GitHub Auth where any GitHub user would be allowed access to Jenkins. Using matrix authorization allow restricting access to just users in our teams. The org level restriction did not seem to work. from the Jenkins plugin docs https://plugins.jenkins.io/github-oauth/ You can configure authorization based on GitHub users, organizations, or teams. username  - give permissions to a specific GitHub username. organization  - give permissions to every user that belongs to a specific GitHub organization. organization*team  - give permissions to a specific GitHub team of a GitHub organization. Notice that organization and team are separated by an asterisk ( * ).

          Peter Lieverdink added a comment - - edited

          I think I ran into this when using OIDC authentication. Access for users is managed via their oauth2 groups and even though the documentation says the resource root url has no access checks on it whatsoever, I get:

          HTTP ERROR 403 Failed permission check: cafuego is missing the Overall/Read permission
          URI:	/static-files/lKi4B58HTuaLnaDrAj8BqK168GlCn0_fXcif7-MJL-gxNjI1ODExNDk2MTU2Ojc6Y2FmdWVnbzpqb2IvZHMtdnJ0LzEwMC9hcnRpZmFjdA==/data/anon/html_report/a96f14595379b7c348d66e115ec65a93.png
          STATUS:	403
          MESSAGE:	Failed permission check: cafuego is missing the Overall/Read permission
          SERVLET:	Stapler
          Powered by Jetty:// 9.4.41.v20210516
          

          Dear reader, I do in fact have the Overall/Read permission

          Adding the resource root url hostname to the list of callback URLs on the oauth2 server made no difference.

          Adding a global role to an individual user works around the problem, but the whole idea of roles is that I no longer need to manage individual users on yet another system.

          The docs I mentioned above also note that the resource root url functionality was added to core in 2.290. I'm on 2.2892 LTS, so it's possible an update could resolve the issue. Is anyone else who is experience this problem on 2.290 or newer?

          Peter Lieverdink added a comment - - edited I think I ran into this when using OIDC authentication. Access for users is managed via their oauth2 groups and even though the documentation says the resource root url has no access checks on it whatsoever, I get: HTTP ERROR 403 Failed permission check: cafuego is missing the Overall/Read permission URI: / static -files/lKi4B58HTuaLnaDrAj8BqK168GlCn0_fXcif7-MJL-gxNjI1ODExNDk2MTU2Ojc6Y2FmdWVnbzpqb2IvZHMtdnJ0LzEwMC9hcnRpZmFjdA==/data/anon/html_report/a96f14595379b7c348d66e115ec65a93.png STATUS: 403 MESSAGE: Failed permission check: cafuego is missing the Overall/Read permission SERVLET: Stapler Powered by Jetty: // 9.4.41.v20210516 Dear reader, I do in fact have the Overall/Read permission Adding the resource root url hostname to the list of callback URLs on the oauth2 server made no difference. Adding a global role to an individual user works around the problem, but the whole idea of roles is that I no longer need to manage individual users on yet another system. The docs I mentioned above also note that the resource root url functionality was added to core in 2.290. I'm on 2.2892 LTS, so it's possible an update could resolve the issue. Is anyone else who is experience this problem on 2.290 or newer?

          "Is anyone else who is experience this problem on 2.290 or newer?"

          Not on >=v2.290 but I can validate the problem exists on v2.289.2 (current LTS). We're also using OIDC authn. Have removed resource root URL for the time being - not ideal.

          Brendan Holmes added a comment - "Is anyone else who is experience this problem on 2.290 or newer?" Not on >=v2.290 but I can validate the problem exists on v2.289.2 (current LTS). We're also using OIDC authn. Have removed resource root URL for the time being - not ideal.

          Cristian added a comment -

          I see the same issue using the Role-based Authorization Strategy.

          In fact I have even seen it with the (not project based) Matrix Authorization intermitently. Like in it works most of the time, but sometimes I get the error, refresh the page and it works again.

          Cristian added a comment - I see the same issue using the Role-based Authorization Strategy. In fact I have even seen it with the (not project based) Matrix Authorization intermitently. Like in it works most of the time, but sometimes I get the error, refresh the page and it works again.

          Cristian added a comment - - edited

          In my case the problem was that the permissions had been given to my username as it came from GitHub, with capital letters. Giving permissions to the same user, all lowercase, fixed the issue.

          In most parts of the user interface Jenkins seems to treat "username" and "UserName" like the same. But if I delete the permissions from "UserName" then I lose access to Jenkins. So I need to keep both...

          Cristian added a comment - - edited In my case the problem was that the permissions had been given to my username as it came from GitHub, with capital letters. Giving permissions to the same user, all lowercase, fixed the issue. In most parts of the user interface Jenkins seems to treat "username" and "UserName" like the same. But if I delete the permissions from "UserName" then I lose access to Jenkins. So I need to keep both...

          Chris Beswick added a comment -

          I had this occur recently with the AzureAD Matrix strategy. 

          To solve it I also had to give the "Authenticated Users" Group, Overall Read access permission also.

          Chris Beswick added a comment - I had this occur recently with the AzureAD Matrix strategy.  To solve it I also had to give the "Authenticated Users" Group, Overall Read access permission also.

          Fabian Holler added a comment - - edited

          We experience the issue on Jenkins 2.346.2.

          In Jenkins we have the "Resource Root URL" configured  and archive HTML pages as artifact. We access the artifact via the latest link from the job. The job runs every ~1-10min and generates a new artifact.

          Often accessing the html artifact fails with this 403 permission error. After ~5-10 refreshing the page it then suddenly works. Multiple users have this issue.

           

          We use Matrix-based Security and the GitHub Auth Plugin. We granted all Authenticated Users, all Github Org and individual Github Groups overall:read permissions.

          Granting individual users additional the overall:read permissions did not help.

           

          Update 2022/10/12: I encountered the error now also 1x when I tried to start a build via the Jenkins CLI over SSH client (`build <JOB-NAME>`). When I retried the same a second time it worked.

          Fabian Holler added a comment - - edited We experience the issue on Jenkins 2.346.2. In Jenkins we have the "Resource Root URL" configured  and archive HTML pages as artifact. We access the artifact via the latest link from the job. The job runs every ~1-10min and generates a new artifact. Often accessing the html artifact fails with this 403 permission error. After ~5-10 refreshing the page it then suddenly works. Multiple users have this issue.   We use Matrix-based Security and the GitHub Auth Plugin. We granted all Authenticated Users, all Github Org and individual Github Groups overall:read permissions. Granting individual users additional the overall:read permissions did not help.   Update 2022/10/12: I encountered the error now also 1x when I tried to start a build via the Jenkins CLI over SSH client (`build <JOB-NAME>`). When I retried the same a second time it worked.

            Unassigned Unassigned
            d1morto Donald Morton
            Votes:
            11 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated: