[
https://issues.apache.org/jira/browse/RANGER-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manohar Vanam updated RANGER-3964:
----------------------------------
Description:
I observed some behaviour change in ranger 2.3.0 vs ranger 2.1.0 (with same
file/folder permissions & ranger policies)
{code:java}
2.1.0:
HDFS User:
Here using HDFS user just to get permission on folder
bash-4.2$ hdfs dfs -ls /odh/apps/2.0.0/tez/
Found 1 items
-r--r--r-- 3 hdfs hadoop 73155475 2022-11-08 12:25
/odh/apps/2.0.0/tez/tez.tar.gz
Hive User:
bash-4.2$ hdfs dfs -ls /odh/apps/2.0.0/tez/tez.tar.gz
-r--r--r-- 3 hdfs hadoop 73155475 2022-11-08 12:25
/odh/apps/2.0.0/tez/tez.tar.gz
bash-4.2$ hdfs dfs -ls /services
ls: `/services': No such file or directory
2.3.0:
HDFS USER:
Here using HDFS user just to get permission on folder
bash-4.2$ hdfs dfs -ls /odh/apps/2.0.0/tez/
Found 1 items
-r--r--r-- 3 hdfs hadoop 73165217 2022-11-07 20:26
/odh/apps/2.0.0/tez/tez.tar.gz
Hive User:
bash-4.2$ hdfs dfs -ls /odh/apps/2.0.0/tez/tez.tar.gz
ls:
org.apache.ranger.authorization.hadoop.exceptions.RangerAccessControlException:
Permission denied: user=hive, access=EXECUTE,
inode="/odh/apps/2.0.0/tez/tez.tar.gz"
bash-4.2$ hdfs dfs -ls /services
ls:
org.apache.ranger.authorization.hadoop.exceptions.RangerAccessControlException:
Permission denied: user=hive, access=EXECUTE, inode="/"
{code}
# /odh/apps/2.0.0/tez/tez.tar.gz has the same permissions & policies, with
*Hive* user In Ranger 2.1.0 list command is giving result, but in ranger 2.3.0
throwing RangerAccessControlException for EXECUTE permission.
# If we try to list non-existing directory in this case {*}/services{*},
with *Hive* user In Ranger 2.1.0 list command is giving *{_}No such file or
directory message{_},* but in ranger 2.3.0 *_throwing
RangerAccessControlException for EXECUTE permission._*
Is it a bug/ behaviour change ? Is it mandatory to provide *EXECUTE* permission
for listing file/directories from Ranger 2.3.0 version?
RANGER-3294 Is this change the reason for this behaviour, please correct me if
I wrong.
was:
I observed some behaviour change in ranger 2.3.0 vs ranger 2.1.0 (with same
file/folder permissions & ranger policies)
{code:java}
2.1.0:
HDFS User:
Here using HDFS user just to get permission on folder
bash-4.2$ hdfs dfs -ls /odh/apps/2.0.0/tez/
Found 1 items
-r--r--r-- 3 hdfs hadoop 73155475 2022-11-08 12:25
/odh/apps/2.0.0/tez/tez.tar.gz
Hive User:
bash-4.2$ hdfs dfs -ls /odh/apps/2.0.0/tez/tez.tar.gz
-r--r--r-- 3 hdfs hadoop 73155475 2022-11-08 12:25
/odh/apps/2.0.0/tez/tez.tar.gz
bash-4.2$ hdfs dfs -ls /services
ls: `/services': No such file or directory
2.3.0:
HDFS USER:
Here using HDFS user just to get permission on folder
bash-4.2$ hdfs dfs -ls /odh/apps/2.0.0/tez/
Found 1 items
-r--r--r-- 3 hdfs hadoop 73165217 2022-11-07 20:26
/odh/apps/2.0.0/tez/tez.tar.gz
Hive User:
bash-4.2$ hdfs dfs -ls /odh/apps/2.0.0/tez/tez.tar.gz
ls:
org.apache.ranger.authorization.hadoop.exceptions.RangerAccessControlException:
Permission denied: user=hive, access=EXECUTE,
inode="/odh/apps/2.0.0/tez/tez.tar.gz"
bash-4.2$ hdfs dfs -ls /services
ls:
org.apache.ranger.authorization.hadoop.exceptions.RangerAccessControlException:
Permission denied: user=hive, access=EXECUTE, inode="/"
{code}
# /odh/apps/2.0.0/tez/tez.tar.gz has the same permissions & policies, with
*Hive* user In Ranger 2.1.0 list command is giving result, but in ranger 2.3.0
throwing RangerAccessControlException for EXECUTE permission.
# If we try to list non-existing directory in this case {*}/services{*},
with *Hive* user In Ranger 2.1.0 list command is giving *{_}No such file or
directory message{_},* but in ranger 2.3.0 *_throwing
RangerAccessControlException for EXECUTE permission._*
Is it a bug/ behaviour change ? Is it mandatory to provide *EXECUTE* permission
for listing file/directories from Ranger 2.3.0 version?
> Behaviour change in ranger 2.3.0 vs ranger 2.1.0
> -------------------------------------------------
>
> Key: RANGER-3964
> URL: https://issues.apache.org/jira/browse/RANGER-3964
> Project: Ranger
> Issue Type: Bug
> Components: Ranger
> Affects Versions: 2.3.0
> Reporter: Manohar Vanam
> Priority: Major
>
> I observed some behaviour change in ranger 2.3.0 vs ranger 2.1.0 (with same
> file/folder permissions & ranger policies)
>
> {code:java}
> 2.1.0:
> HDFS User:
> Here using HDFS user just to get permission on folder
> bash-4.2$ hdfs dfs -ls /odh/apps/2.0.0/tez/
> Found 1 items
> -r--r--r-- 3 hdfs hadoop 73155475 2022-11-08 12:25
> /odh/apps/2.0.0/tez/tez.tar.gz
> Hive User:
> bash-4.2$ hdfs dfs -ls /odh/apps/2.0.0/tez/tez.tar.gz
> -r--r--r-- 3 hdfs hadoop 73155475 2022-11-08 12:25
> /odh/apps/2.0.0/tez/tez.tar.gz
> bash-4.2$ hdfs dfs -ls /services
> ls: `/services': No such file or directory
>
> 2.3.0:
> HDFS USER:
> Here using HDFS user just to get permission on folder
> bash-4.2$ hdfs dfs -ls /odh/apps/2.0.0/tez/
> Found 1 items
> -r--r--r-- 3 hdfs hadoop 73165217 2022-11-07 20:26
> /odh/apps/2.0.0/tez/tez.tar.gz
> Hive User:
> bash-4.2$ hdfs dfs -ls /odh/apps/2.0.0/tez/tez.tar.gz
> ls:
> org.apache.ranger.authorization.hadoop.exceptions.RangerAccessControlException:
> Permission denied: user=hive, access=EXECUTE,
> inode="/odh/apps/2.0.0/tez/tez.tar.gz"
> bash-4.2$ hdfs dfs -ls /services
> ls:
> org.apache.ranger.authorization.hadoop.exceptions.RangerAccessControlException:
> Permission denied: user=hive, access=EXECUTE, inode="/"
> {code}
>
> # /odh/apps/2.0.0/tez/tez.tar.gz has the same permissions & policies, with
> *Hive* user In Ranger 2.1.0 list command is giving result, but in ranger
> 2.3.0 throwing RangerAccessControlException for EXECUTE permission.
> # If we try to list non-existing directory in this case {*}/services{*},
> with *Hive* user In Ranger 2.1.0 list command is giving *{_}No such file or
> directory message{_},* but in ranger 2.3.0 *_throwing
> RangerAccessControlException for EXECUTE permission._*
> Is it a bug/ behaviour change ? Is it mandatory to provide *EXECUTE*
> permission for listing file/directories from Ranger 2.3.0 version?
>
> RANGER-3294 Is this change the reason for this behaviour, please correct me
> if I wrong.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
