[
https://issues.apache.org/jira/browse/HDDS-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17333562#comment-17333562
]
Neil Joshi edited comment on HDDS-4335 at 4/27/21, 10:24 PM:
-------------------------------------------------------------
Ozone fs shell POSIX permissions are not used for access control checks against
object read/write/view operations. Instead, currently access control is
checked against access control policies provided by ozone native ACL or
external Apache Ranger.
Since permissions are provided and checked with object store access control
mechanisms, the POSIX file system permissions are hardcoded to read/write and
viewable for all users (owner,group,user - rwxrwxrwx).
The example provided with this Jira is not an issue as described as the ozone
setup _will_ provide access control for ozone fs shell file creation and
modification _given_ it is run on a secure cluster (enabled native acl /
ranger). This is illustrated below:
with two users defined, user _testuser_ and user _testuser2_ :
set current user to _testuser_, create volume vol1 and grant access to vol1 to
both users _testuser_ and _testuser2_.
{code:java}
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ kinit -kt
/etc/security/keytabs/testuser.keytab testuser/[email protected]
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
sh volume create vol1
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
sh volume setacl /vol1
--acls=user:testuser/[email protected]:a,group:root:a,user:testuser2/[email protected]:a
{code}
create bucket and key: *_vol1/bucket1/data/sandbox/poc/teragen_*
{code:java}
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
fs -mkdir -p /vol1/bucket1/data/sandbox/poc/teragen
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
fs -ls -R /vol1/bucket1/data/sandbox/poc
Found 1 items
drwxrwxrwx - root root 0 2021-04-27 20:10
/vol1/bucket1/data/sandbox/poc/teragen {code}
set current user to _testuser2_, attempt to list and delete
*_/vol1/bucket1/data/sandbox/poc/teragen_*
{code:java}
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ kinit -kt
/etc/security/keytabs/testuser2.keytab testuser2/[email protected]
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
fs -ls -R /vol1/bucket1/data/sandbox/poc
ls: `/vol1/bucket1/data/sandbox/poc': No such file or directory
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
fs -rm -R /vol1/bucket1/data/sandbox/poc
rm: `/vol1/bucket1/data/sandbox/poc': No such file or directory {code}
user _testuser2_ cannot access bucket/key created by _testuser_
switch to _testuser_ and repeat
{code:java}
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ kinit -kt
/etc/security/keytabs/testuser.keytab testuser/[email protected]
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
fs -ls -R /vol1/bucket1/data/sandbox/poc
Found 1 items
drwxrwxrwx - root root 0 2021-04-27 20:10
/vol1/bucket1/data/sandbox/poc/teragen
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
fs -rm -R -skipTrash /vol1/bucket1/data/sandbox/poc Deleted
/vol1/bucket1/data/sandbox/poc{code}
In the secure ozone deployment access controls *_restrict_* user _testuser2_
from accessing and deleting keys created/owned by _testuser_ which is the
behavior the jiri was opened to test.
was (Author: neiljoshi):
Ozone fs shell POSIX permissions are not used for access control checks against
object read/write/view operations. Instead, currently access control is
checked against access control policies provided by ozone native ACL or
external Apache Ranger.
Since permissions are provided and checked with object store access control
mechanisms, the POSIX file system permissions are hardcoded to read/write and
viewable for all users (owner,group,user - rwxrwxrwx).
The example provided with this Jira is not an issue as described as the ozone
setup _will_ provide access control for ozone fs shell file creation and
modification _given_ it is run on a secure cluster (enabled native acl /
ranger). This is illustrated below:
with two users defined, user _testuser_ and user _testuser2_ :
set current user to _testuser_, create volume vol1 and grant access to vol1 to
both users _testuser_ and _testuser2_.
{code:java}
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ kinit -kt
/etc/security/keytabs/testuser.keytab testuser/[email protected]
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
sh volume create vol1
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
sh volume setacl /vol1
--acls=user:testuser/[email protected]:a,group:root:a,user:testuser2/[email protected]:a
{code}
create bucket and key: *_vol1/bucket1/data/sandbox/poc/teragen_*
{code:java}
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
fs -mkdir -p /vol1/bucket1/data/sandbox/poc/teragen
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
fs -ls -R /vol1/bucket1/data/sandbox/poc
Found 1 items
drwxrwxrwx - root root 0 2021-04-27 20:10
/vol1/bucket1/data/sandbox/poc/teragen {code}
set current user to _testuser2_, attempt to list and delete
*_/vol1/bucket1/data/sandbox/poc/teragen_*
{code:java}
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ kinit -kt
/etc/security/keytabs/testuser2.keytab testuser2/[email protected]
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
fs -ls -R /vol1/bucket1/data/sandbox/poc
ls: `/vol1/bucket1/data/sandbox/poc': No such file or directory
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
fs -rm -r /vol1/bucket1/data/sandbox/poc
rm: `/vol1/bucket1/data/sandbox/poc': No such file or directory {code}
user _testuser2_ cannot access bucket/key created by _testuser_
switch to _testuser_ and repeat
{code:java}
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ kinit -kt
/etc/security/keytabs/testuser.keytab testuser/[email protected]
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
fs -ls -R /vol1/bucket1/data/sandbox/poc
Found 1 items
drwxrwxrwx - root root 0 2021-04-27 20:10
/vol1/bucket1/data/sandbox/poc/teragen
hadoop-ozone/dist/target/ozone-SNAPSHOT/compose/ozonesecure bash-4.2$ bin/ozone
fs -rm -r -skipTrash /vol1/bucket1/data/sandbox/poc Deleted
/vol1/bucket1/data/sandbox/poc{code}
In the secure ozone deployment access controls *_restrict_* user _testuser2_
from accessing and deleting keys created/owned by _testuser_ which is the
behavior the jiri was opened to test.
> No user access checks in Ozone FS
> ---------------------------------
>
> Key: HDDS-4335
> URL: https://issues.apache.org/jira/browse/HDDS-4335
> Project: Apache Ozone
> Issue Type: Bug
> Reporter: Shashikant Banerjee
> Assignee: Neil Joshi
> Priority: Major
>
> Currently, a dir/file created with hdfs user cab be deleted by any user.
> {code:java}
> [sbanerjee@vd1308 MapReduce-Performance_Testing-master]$ sudo -u hdfs ozone
> fs -mkdir o3fs://bucket1.vol1.ozone1/data/sandbox/poc/teragen
> [sbanerjee@vd1308 MapReduce-Performance_Testing-master]$ sudo -u hdfs ozone
> fs -ls o3fs://bucket1.vol1.ozone1/data/sandbox/poc/teragen
> [sbanerjee@vd1308 MapReduce-Performance_Testing-master]$ sudo -u hdfs ozone
> fs -ls o3fs://bucket1.vol1.ozone1/data/sandbox/poc/
> Found 1 items
> drwxrwxrwx - hdfs hdfs 0 2020-10-12 02:51
> o3fs://bucket1.vol1.ozone1/data/sandbox/poc/teragen
> [sbanerjee@vd1308 MapReduce-Performance_Testing-master]$
> [sbanerjee@vd1308 MapReduce-Performance_Testing-master]$
> [sbanerjee@vd1308 MapReduce-Performance_Testing-master]$
> [sbanerjee@vd1308 MapReduce-Performance_Testing-master]$ ozone fs -rm -r
> o3fs://bucket1.vol1.ozone1/data/sandbox/poc/
> 20/10/12 02:52:16 INFO Configuration.deprecation: io.bytes.per.checksum is
> deprecated. Instead, use dfs.bytes-per-checksum
> 20/10/12 02:52:16 INFO ozone.BasicOzoneFileSystem: Move to trash is disabled
> for o3fs, deleting instead: o3fs://bucket1.vol1.ozone1/data/sandbox/poc.
> Files or directories will NOT be retained in trash. Ignore the following
> TrashPolicyDefault message, if any.
> 20/10/12 02:52:16 INFO fs.TrashPolicyDefault: Moved:
> 'o3fs://bucket1.vol1.ozone1/data/sandbox/poc' to trash at:
> /.Trash/sbanerjee/Current/data/sandbox/poc1602496336480
> [sbanerjee@vd1308 MapReduce-Performance_Testing-master]$ sudo -u hdfs ozone
> fs -ls o3fs://bucket1.vol1.ozone1/data/sandbox/poc/
> ls: `o3fs://bucket1.vol1.ozone1/data/sandbox/poc/': No such file or directory
> {code}
> Whereas, the same seuquence fails with permission denied error in HDFS.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
