+1 for Pramod's proposal for impersonation. I have an issue with Sandesh's suggestion about making the new behavior as the default (or only) behavior. This will introduce incompatibility with other legacy tools (e.g. Datatorrent's dtGateway) that assume user A's HDFS path as the application path. Because the legacy tools will continue to assume the old path (user A's path) they will not work with the Apex core that has this change.
The current behavior might also be preferable to certain users or their administrators because of not having to deal with multiple HDFS user directories (for administration, logging, backup etc). On Thu, May 18, 2017 at 4:01 PM, Sandesh Hegde <sand...@datatorrent.com> wrote: > My vote is to make the new proposal as the default behavior. Is there a use > case for the current behavior? If not then no need to add the configuration > setting. > > On Thu, May 18, 2017 at 3:47 PM Pramod Immaneni <pra...@datatorrent.com> > 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/apex/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 > > > > > >
