apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pramod Immaneni <pra...@datatorrent.com>
Subject impersonation and application path
Date Thu, 18 May 2017 22:44:15 GMT
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

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