apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pramod Immaneni <pra...@datatorrent.com>
Subject Re: impersonation and application path
Date Fri, 19 May 2017 14:57:49 GMT
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.rozov@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 <pramod@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
>>>
>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message