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 <bhara...@cloudera.com> 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 <mhdwrkoff...@gmail.com> 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 *"ad...@example.com <ad...@example.com>"* >>> I0102 03:40:07.972348 27948 authentication.cc:445] Successfully >>> authenticated principal *"impala/cdh-...@example.com >>> <cdh-...@example.com>"* 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 <jes...@gmail.com> 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 <bhara...@cloudera.com> >>> 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 <mhdwrkoff...@gmail.com> 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/hostn...@example.com) instead of the currently connected >>> user. >>> >> >>> >> Is this a known issue or limitation of Impala? >>> >>
