[
https://issues.apache.org/jira/browse/NIFI-5033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16419993#comment-16419993
]
Matt Gilman edited comment on NIFI-5033 at 3/30/18 12:13 AM:
-------------------------------------------------------------
Hey [~pvillard] thanks for filing this! I see what's going on... There are
actually two issues here one of which is a regression from 1.5.0.
1) The new granular restricted components introduced custom implementations of
checkAuthorization (happens if we are checking a user's permissions so we can
enable some UI feature) and authorize (happens if a user is actually attempting
to interact with some component). By its signature, checkAuthorization should
never throw any exceptions. If the user is unauthorized it should return
AuthorizationResult.Denied. Conservely, authorize should throw an
AccessDeniedException when the user is unauthorized. The regression in 1.6.0 is
that we introduced a checkAuthorization method which throws an
AccessDeniendException when the user is null. By its definition, it should
simply return AuthorizationResult.Denied.
2) The other issue that was present in previous releases is that the user is
null here. This should not be the case even in unsecured mode. Instead, the
user object should be populated with an anonymous user. The request in question
is an asynchronous request meaning we hold a reference to the user in memory to
process each step. By passing a null user object, it likely meant that an
intermediate step of the variable update request returned the wrong permission
indicators (by invoking checkAuthorization). In this case, it stated the user
was not allowed to access some component since the user reference was not used
when generated a response for the client. However, because it was an
intermediate step and not the final result (which did correctly use the user
reference) this was unnoticed.
was (Author: mcgilman):
Hey [~pvillard] thanks for filing this! I see what's going on... There are
actually two issues here one of which is a regression from 1.5.0.
1) The new granular restricted components introduced custom implementations of
checkAuthorization (happens if we are checking a user's permissions so we can
enable some UI feature) and authorize (happens if a user is actually attempting
to interact with some component). By its signature, checkAuthorization should
never throw any exceptions. If the user is unauthorized it should return
AuthorizationResult.Denied. Conservely, authorize should throw an
AccessDeniedException when the user is unauthorized. The regression in 1.6.0 is
that we introduced a checkAuthorization method which throws an
AccessDeniendException when the user is null. By its definition, it should
simply return AuthorizationResult.Denied.
2) The other issue that was present in previous releases is that the user is
null here. This should not be the case even in unsecured mode. Instead, the
user object should be populated with an anonymous user. The request in question
is an asynchronous request meaning we hold a reference to the user in memory to
process each step. The passing a null user object, it likely meant that an
intermediate step of the variable update request returned the wrong permission
indicators (invoking checkAuthorization). In this case, it stated the user was
not allowed to access some component since the user reference was not used when
generated a response for the client. However, because it was an intermediate
step and not the final result (which did correctly use the user reference) this
was unnoticed.
> Cannot update variable referenced in restricted components
> ----------------------------------------------------------
>
> Key: NIFI-5033
> URL: https://issues.apache.org/jira/browse/NIFI-5033
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 1.6.0
> Reporter: Pierre Villard
> Priority: Blocker
>
> When updating a variable at pg level that references a restricted component
> it will fail. It seems the code is the same for secured and unsecured
> instance and it fails when NiFi is unsecured since the user is unknown.
> It seems it has been introduced by NIFI-4885.
> {noformat}
> 2018-03-29 21:10:30,913 INFO [Variable Registry Update Thread]
> o.a.nifi.web.api.ProcessGroupResource In order to update Variable Registry
> for Process Group with ID 731bbdde-0162-1000-0f00-db6543c34b50, Stopping
> Processors
> 2018-03-29 21:10:30,913 INFO [Variable Registry Update Thread]
> o.a.nifi.web.api.ProcessGroupResource In order to update Variable Registry
> for Process Group with ID 731bbdde-0162-1000-0f00-db6543c34b50, Disabling
> Controller Services
> 2018-03-29 21:10:30,913 INFO [Variable Registry Update Thread]
> o.a.nifi.web.api.ProcessGroupResource In order to update Variable Registry
> for Process Group with ID 731bbdde-0162-1000-0f00-db6543c34b50, Applying
> updates to Variable Registry
> 2018-03-29 21:10:30,915 ERROR [Variable Registry Update Thread]
> o.a.nifi.web.api.ProcessGroupResource Failed to update variable registry for
> Process Group with ID 731bbdde-0162-1000-0f00-db6543c34b50
> org.apache.nifi.authorization.AccessDeniedException: Unknown user.
> at
> org.apache.nifi.authorization.resource.RestrictedComponentsAuthorizableFactory$2.checkAuthorization(RestrictedComponentsAuthorizableFactory.java:68)
> at
> org.apache.nifi.controller.ConfiguredComponent.checkAuthorization(ConfiguredComponent.java:129)
> at
> org.apache.nifi.authorization.resource.Authorizable.checkAuthorization(Authorizable.java:183)
> at
> org.apache.nifi.authorization.resource.Authorizable.isAuthorized(Authorizable.java:70)
> at
> org.apache.nifi.web.api.dto.DtoFactory.createPermissionsDto(DtoFactory.java:1798)
> at
> org.apache.nifi.web.api.dto.DtoFactory.createPermissionsDto(DtoFactory.java:1785)
> at
> org.apache.nifi.web.api.dto.DtoFactory.lambda$createAffectedComponentEntities$73(DtoFactory.java:2485)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at
> java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1540)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at
> org.apache.nifi.web.api.dto.DtoFactory.createAffectedComponentEntities(DtoFactory.java:2489)
> at
> org.apache.nifi.web.api.dto.DtoFactory.createVariableRegistryDto(DtoFactory.java:2507)
> at
> org.apache.nifi.web.StandardNiFiServiceFacade.lambda$updateVariableRegistry$36(StandardNiFiServiceFacade.java:950)
> at
> org.apache.nifi.web.StandardNiFiServiceFacade$1.update(StandardNiFiServiceFacade.java:721)
> at
> org.apache.nifi.web.revision.NaiveRevisionManager.updateRevision(NaiveRevisionManager.java:120)
> at
> org.apache.nifi.web.StandardNiFiServiceFacade.updateComponent(StandardNiFiServiceFacade.java:712)
> at
> org.apache.nifi.web.StandardNiFiServiceFacade.updateVariableRegistry(StandardNiFiServiceFacade.java:947)
> at
> org.apache.nifi.web.StandardNiFiServiceFacade$$FastClassBySpringCGLIB$$358780e0.invoke(<generated>)
> at
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:738)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> at
> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:85)
> at
> org.apache.nifi.web.NiFiServiceFacadeLock.proceedWithWriteLock(NiFiServiceFacadeLock.java:173)
> at
> org.apache.nifi.web.NiFiServiceFacadeLock.updateLock(NiFiServiceFacadeLock.java:66)
> at sun.reflect.GeneratedMethodAccessor585.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:629)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:618)
> at
> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:70)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:673)
> at
> org.apache.nifi.web.StandardNiFiServiceFacade$$EnhancerBySpringCGLIB$$8b963f6e.updateVariableRegistry(<generated>)
> at
> org.apache.nifi.web.api.ProcessGroupResource$3.lambda$run$2(ProcessGroupResource.java:1191)
> at
> org.apache.nifi.web.api.ProcessGroupResource.performUpdateVariableRegistryStep(ProcessGroupResource.java:1244)
> at
> org.apache.nifi.web.api.ProcessGroupResource.access$000(ProcessGroupResource.java:175)
> at
> org.apache.nifi.web.api.ProcessGroupResource$3.run(ProcessGroupResource.java:1189)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 2018-03-29 21:10:30,917 INFO [Variable Registry Update Thread]
> o.a.nifi.web.api.ProcessGroupResource In updating Variable Registry for
> Process Group with ID 731bbdde-0162-1000-0f00-db6543c34b50, skipping the
> following step because the request has completed already: Re-enabling
> Controller Services
> 2018-03-29 21:10:30,917 INFO [Variable Registry Update Thread]
> o.a.nifi.web.api.ProcessGroupResource In updating Variable Registry for
> Process Group with ID 731bbdde-0162-1000-0f00-db6543c34b50, skipping the
> following step because the request has completed already: Restarting
> Processors{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
