AnsweredAssumed Answered

impala user permissions

Question asked by mgrechukh on Nov 4, 2016
Latest reply on Nov 14, 2016 by Hao Zhu

We encountered the problem with impala that looks like always execute requests as the user mapr (admin superuser of our mapr cluster) and we did not found the way to limit rights for impalad on folders.


Recently we encountered the problem when developer is wrongly defined the location for the table and destroyed all users data in folder.


To reproduce it enough to execute from impala-shell the following commands:


create table test (val string) location '/demo;

drop table test;



All data from the /demo folder will be vanished, even if your user does not have any rights for it.


Below is the detailed example how it can be reproduced:


On volume /demo I created folders for three users. Each user has write access to his own directory only.


[demo_c@hadoopdev01] $ hadoop fs -ls /demo/


Found 3 items

drwxr-xr-x   - demo_a root          0 2016-11-04 14:58 /demo/a

drwxr-xr-x   - demo_b root          0 2016-11-04 14:58 /demo/b

drwxr-xr-x   - demo_c root          0 2016-11-04 14:58 /demo/c


As user demo_c I can verify that write not allowed:


[demo_c@hadoopdev01] $ hadoop fs -mkdir /demo/test


2016-11-04 15:11:43,1250 ERROR Client fs/client/fileclient/cc/ Thread: 18164 TraverseAndCreateDirs failed, could not create test, error Permission denied(13), parentFid 2309.16.2

2016-11-04 15:11:43,1251 ERROR JniCommon fs/client/fileclient/cc/ Thread: 18164 mkdirs failed for /demo/test, error 13

mkdir: User demo_c(user id 9003)  has been denied access to create test


Which is correct.


Now starting impala-shell as user demo_c :


[demo_c@hadoopdev01]  $ impala-shell

Starting Impala Shell without Kerberos authentication

Connected to hadoopdev01.local:21000

Server version: impalad version 2.5.0 RELEASE (build 30f7100ab2cd519b1f02c81a015d1792fe11c8c1)


Welcome to the Impala shell. Copyright (c) 2015 Cloudera, Inc. All rights reserved.

(Impala Shell v2.5.0 (30f7100) built on Thu Jun 23 05:41:51 UTC 2016)


Run the PROFILE command after a query has finished to see a comprehensive summary

of all the performance and diagnostic information that Impala gathered for that

query. Be warned, it can be very long!



I create table, specifying another user’s directory as location, where I have no write access to:


[hadoopdev01.auchan.local:21000] > create table demotest (val string) location '/demo/a';

Query: create table demotest (val string) location '/demo/a'


Fetched 0 row(s) in 0.07s


[hadoopdev01.:21000] > insert into demotest values ("hello") ;


Query: insert into demotest values ("hello")

ERROR: AnalysisException: Unable to INSERT into target table (default.demotest) because Impala does not have WRITE access to at least one HDFS path: maprfs:/demo/a


[hadoopdev01.local:21000] > drop table demotest;

Query: drop table demotest

[hadoopdev01.local:21000] > Goodbye demo_c


-sh-4.2$ hadoop fs -ls /demo

Found 2 items

drwxr-xr-x   - demo_b root          0 2016-11-04 14:58 /demo/b

drwxr-xr-x   - demo_c root          0 2016-11-04 14:58 /demo/c


So directory /demo/a silently removed by Impala regardless of access permissions.


Another test, as unprivileged user in impala-shell I can do “Create table location '/demo/'” then drop it, - whole /demo folder vanished although again user can not write there.


So our question is - what is the way to protect data from the impala purging?

We already tried to activate the impersonation for impala by adding the:


But no success. Looks like that drop always executed as mapr.