Sounds good. Also I would like to work on this so the JIRA can be assigned to me.
On Mon, May 22, 2017 at 3:06 PM, Pramod Immaneni <pra...@datatorrent.com> wrote: > I see the advantage in having a top level setting that says use > "impersonating user" vs "impersonated user" resources. This can internally > switch the resources, there could be resources other than application path > in future and they would also be covered. I would still leave the default > to be the impersonating user as not all setups fall into this category and > in many cases, user's directories are not created or managed in hdfs and > also it would be backward compatible. > > I think everyone seems to agree on the functionality but there is a > difference of opinion on the implementation. I will call out a vote on the > different implementation options and we can move forward. > > Thanks > > > On Fri, May 19, 2017 at 11:58 AM, Sanjay Pujare <san...@datatorrent.com> > wrote: > > > I agree. But how do we use APPLICATION_PATH for this purpose since we > need > > a Yes/No flag to specify new vs old behavior? > > > > So we have to use a new setting for this (something like > > USE_RUNTIME_USER_APPLICATION_PATH ?) > > > > On Fri, May 19, 2017 at 7:57 AM, Pramod Immaneni <pra...@datatorrent.com > > > > wrote: > > > > > I wouldn't necessarily consider the current behavior a bug and the > > default > > > is fine the way it is today, especially because the user launching the > > app > > > is not the user. APPLICATION_PATH can be used as the setting. > > > > > > On Fri, May 19, 2017 at 7:43 AM, Vlad Rozov <v.ro...@datatorrent.com> > > > wrote: > > > > > > > Do I understand correctly that the question is regarding > > > > DAGContext.APPLICATION_PATH attribute value in case it is not > defined? > > In > > > > this case, I would treat the current behavior as a bug and +1 the > > > proposal > > > > to set it to the impersonated user B DFS home directory. As > > > > APPLICATION_PATH can be explicitly set I do not see a need to provide > > > > another settings to preserve the current behavior. > > > > > > > > Thank you, > > > > > > > > Vlad > > > > > > > > > > > > On 5/18/17 15:46, Pramod Immaneni wrote: > > > > > > > >> Sorry typo in sentence "as we are not asking for permissions for a > > lower > > > >> privilege", please read as "as we are now asking for permissions > for a > > > >> lower privilege". > > > >> > > > >> On Thu, May 18, 2017 at 3:44 PM, Pramod Immaneni < > > > pra...@datatorrent.com> > > > >> wrote: > > > >> > > > >> Apex cli supports impersonation in secure mode. With impersonation, > > the > > > >>> user running the cli or the user authenticating with hadoop > > (henceforth > > > >>> referred to as login user) can be different from the effective user > > > with > > > >>> which the actions are performed under hadoop. An example for this > is > > an > > > >>> application can be launched by user A to run in hadoop as user B. > > This > > > is > > > >>> kind of like the sudo functionality in unix. You can find more > > details > > > >>> about the functionalilty here https://apex.apache.org/docs/a > > > >>> pex/security/ in > > > >>> the Impersonation section. > > > >>> > > > >>> What happens today with launching an application with > impersonation, > > > >>> using > > > >>> the above launch example, is that even though the application runs > as > > > >>> user > > > >>> B it still uses user A's hdfs path for the application path. The > > > >>> application path is where the artifacts necessary to run the > > > application > > > >>> are stored and where the runtime files like checkpoints are stored. > > > This > > > >>> means that user B needs to have read and write access to user A's > > > >>> application path folders. > > > >>> > > > >>> This may not be allowed in certain environments as it may be a > policy > > > >>> violation for the following reason. Because user A is able to > > > impersonate > > > >>> as user B to launch the application, A is considered to be a higher > > > >>> privileged user than B and is given necessary privileges in hadoop > to > > > do > > > >>> so. But after launch B needs to access folders belonging to A which > > > could > > > >>> constitute a violation as we are not asking for permissions for a > > lower > > > >>> privilege user to access resources of a higher privilege user. > > > >>> > > > >>> I would like to propose adding a configuration setting, which when > > set > > > >>> will use the application path in the impersonated user's home > > directory > > > >>> (user B) as opposed to impersonating user's home directory (user > A). > > If > > > >>> this setting is not specified then the behavior can default to what > > it > > > is > > > >>> today for backwards compatibility. > > > >>> > > > >>> Comments, suggestions, concerns? > > > >>> > > > >>> Thanks > > > >>> > > > >>> > > > > > > > > > >
