Is there any Impala/Sentry specific API we can use inside our code to figure out who current user is?
On Wed, Jan 2, 2019 at 11:12 AM Bharath Vissapragada <[email protected]> wrote: > Yes. I think Jeszy is right. Per my understanding too, we don't > impersonate the client user on the Catalog server. Instead, we enforce the > authorization via Sentry during query planning. > > On Wed, Jan 2, 2019 at 7:06 AM mhd wrk <[email protected]> wrote: > >> IMPALA-2177 sounds like the correct issue. >> Here are log messages from authentication.cc for impalad and catalogd >> respectively: >> >> I0102 14:15:06.722666 28195 authentication.cc:478] Successfully >>> authenticated client user *"[email protected] <[email protected]>"* >>> I0102 03:40:07.972348 27948 authentication.cc:445] Successfully >>> authenticated principal *"impala/[email protected] >>> <[email protected]>"* on an internal connection >> >> >> As you can see from the messages above, impalad is able to identify the >> currently connected user correctly. However catalogd always authenticates >> as impala which causes the problem. >> >> >> On Wed, Jan 2, 2019 at 4:19 AM Jeszy <[email protected]> wrote: >> >>> Hey, >>> >>> IIUC your question correctly, this is a limitation. IMPALA-2177 looks >>> to be the appropriate jira. >>> Most users use Impala together with Sentry, where the recommended >>> approach is to disable impersonation (even in services that allow it, >>> like Hive). >>> >>> HTH >>> >>> On Wed, 2 Jan 2019 at 05:55, Bharath Vissapragada <[email protected]> >>> wrote: >>> > >>> > Hi, >>> > >>> > Can you add the stack trace here if possible? It is not super clear >>> where exactly the problem is. >>> > >>> > Thanks, >>> > Bharath >>> > >>> > On Tue, Jan 1, 2019 at 6:34 PM mhd wrk <[email protected]> wrote: >>> >> >>> >> we have our own implementation of Hadoop FileSystem which relies on >>> current user in a kerberosied environment to locate user specific files in >>> HDFS. This custom file system works fine inside hive to create external >>> tables and query them. However trying to access the same tables via Impala >>> (jdbc driver) fails. Watching the log messages seems that when impalad >>> sends requests to catalogd to get meta data of a given table the current >>> user returned by UserGroupInformation is the service account running the >>> server (impala/[email protected]) instead of the currently connected >>> user. >>> >> >>> >> Is this a known issue or limitation of Impala? >>> >>
