Issue Summary

Access denied error seems to be cached if a plan is visited where you never had permission to and then permission is granted or if it's the first plan you're granted access to after your user account is created.

This is reproducible on Data Center: <TBD>

Steps to Reproduce

It seems to be important that you didn't have permission to it at the time of first accessing it if you have access to other plans/projects that work already. If it's the first project/plan you've ever had permission to, it doesn't matter if you don't visit it first.

1. Create a test user with no permissions to anything unless explicitly granted
2. Create a new project with no permissions
3. Create a new plan in that project with no permissions
4. Only required if this user has access to other projects or plans already (aka for an existing user): Login to the test user and visit http://localhost:8085/browse/PROJ-KEY of the newly created plan
5. Get access denied error
6. Logout and log back in as an administrator
7. Grant plan view + build to the test user
8. Grant project view test user
9. Log back in as the test user
10. Plan is visible on the dashboard, click the link to the plan: Access Denied

Expected Results

Can access the plan as permission has been granted

Actual Results

Cannot access plan. Below is shown in the logs:

2022-05-11 01:25:25,890 WARN [http-nio-8085-exec-22] [AuthorizationLoggerListener] Authorization failed: org.acegisecurity.AccessDeniedException: Access is denied; authenticated principal: org.acegisecurity.adapters.PrincipalAcegiUserToken@63c0e651: Username: EmbeddedCrowdUser{name='perm_test', displayName='Perm Test', directoryId=65537}; Password: [PROTECTED]; Authenticated: true; Details: null; Granted Authorities: ROLE_USER; secure object: ReflectiveMethodInvocation: public abstract boolean com.atlassian.bamboo.plan.PlanManager.assertPlanPermission(com.atlassian.bamboo.plan.PlanIdentifier); target is of class [com.atlassian.bamboo.plan.PlanManagerImpl]; configuration attributes: [ACL_BUILD_READ]
org.acegisecurity.AccessDeniedException: Access is denied
	at org.acegisecurity.vote.AffirmativeBased.decide(AffirmativeBased.java:68)
	at org.acegisecurity.intercept.AbstractSecurityInterceptor.beforeInvocation(AbstractSecurityInterceptor.java:323)
	at org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:63)
	at com.atlassian.bamboo.security.acegi.intercept.aopalliance.AuthorityOverrideMethodSecurityInterceptor.invoke(AuthorityOverrideMethodSecurityInterceptor.java:28)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
	at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:123)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:388)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:215)
	at com.sun.proxy.$Proxy157.assertPlanPermission(Unknown Source)

The WARN log line is shown with default logging but the full stack trace is only present with DEBUG logging.

Workaround

The Bamboo ACL cache needs to be rebuilt. Restart Bamboo and access will work.

If a restart is not feasible, renaming any user will invalidate (it does not have to be the affected user). the cache and force a rebuild. For example:

1. Create a temporary user in the internal directory, and keep the name (example name oldusername)
2. Call the following endpoint which requires administration permissions to change the temporary user's username:

   curl -X PUT --location "$BAMBOO_BASE_URL/rest/api/latest/admin/users/rename" \ -H "Authorization: Bearer $token" \ -H "Content-Type: application/json" \ -d " { \"name\": \"newusername\", \"oldName\": \"oldusername\" }" 
   

3. Verify that the problematic real user can now access the plan
4. The temporary user can be deleted afterwards or kept around for future renames/workaround executions