[ 
https://issues.apache.org/jira/browse/DRILL-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Turton updated DRILL-8135:
--------------------------------
    Fix Version/s:     (was: 1.21.0)

> Option to prevent Impersonation for Metastore
> ---------------------------------------------
>
>                 Key: DRILL-8135
>                 URL: https://issues.apache.org/jira/browse/DRILL-8135
>             Project: Apache Drill
>          Issue Type: Improvement
>          Components: Metadata
>    Affects Versions: 1.20.0
>         Environment: * drill-1.20.0-hadoop2
>  * hadoop 2.9.2
>  * ranger 1.2.0
>            Reporter: Christian Pfarr
>            Priority: Minor
>              Labels: iceberg, metastore
>         Attachments: analyze-table-refresh-metadata.json
>
>
> After enabling iceberg metastore within a kerberized hadoop cluster and 
> enabled impersonation, i have to give all users full access to the metastore 
> directory in hdfs.
> If not, i get an _Permission denied_ when a non-admistator tries to call
> {code:java}
> analyze table hdfs.`dataset` refresh metadata{code}
> I attached the profile with the permission denied error from hdfs/ranger.
> Im not sure if i should call this a bug, because drill should impersonate 
> everything, and so its also impersonating the iceberg metastore. But as an 
> admin i dont want to give all users full write access to the metastore. A 
> unexperienced user could accidentally overwrite something and corrupt the 
> iceberg table or delete metadata completly.
> Maybe we could add a option to drill-metastore-overwrite.conf
> {code:java}
> drill.metastore: {
>   implementation.class: "org.apache.drill.metastore.iceberg.IcebergMetastore",
>   iceberg: {
>     location: {
>       relative_path: "hdfs://nameservice/drill-metastore"
>     },
>     impersonation: {
>       enabled: true,
>       max_chained_user_hops: 3
>     }
>   }
> }{code}
> In my case, i would of course disable it, but to match the behaviour of the 
> general impersonation it could look like this.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to