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? >> >
