You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Matt Gilman (JIRA)" <ji...@apache.org> on 2018/03/30 00:14:00 UTC
[jira] [Comment Edited] (NIFI-5033) Cannot update variable
referenced in restricted components
[ 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)