[
https://issues.apache.org/jira/browse/HDDS-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sammi Chen updated HDDS-5043:
-----------------------------
Description:
This issue aims to fix the incorrect usage of UGI's getUserName in secure mode.
In my test and search code, I Found we couldn't list volume accurately in
secure mode.
(Note: I changed the tittle, some incorrect usage of UGI's getUserName doesn't
matter. Let's focuse on list volume in secure mode.)
Ozone inherits the Hadoop's user login and management mechanism. There are two
user types in Hadoop, one is simple user, another is Kerberos user. For simple
user, it's user name and short user name are identical. For Kerberos user, it's
user name is Kerberos principla, for example, testuser/[email protected], its
short name is testuser. After a kerberos user login, its mapped user in
Hadoop/HDFS is its shortname. Refer to the User Identity section of
[https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html.
|https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html]
So in Ozone, we should follow this rule too. User short name should be used in
# native ACL rule, and native ACL check
# is Ozone admin check
# is Volume/Bucket/Key owner check
was:
This issue aims to fix the incorrect usage of UGI's getUserName in secure mode.
In my test and search code, I Found we couldn't list volume accurately in
secure mode.
(Note: I changed the tittle, some incorrect usage of UGI's getUserName doesn't
matter. Let's focuse on list volume in secure mode.)
Ozone inherits the Hadoop's user login and management mechanism. There are two
user in Hadoop, one is simple user, another is Kerberos user. For simple user,
it's user name and short user name are identical. For Kerberos user, it's user
name is Kerberos principla, for example, testuser/[email protected], its short
name is testuser. After a kerberos user login, its mapped user in Hadoop/HDFS
is its shortname. Refer to the User Identity section of
[https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html.
|https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html]
So in Ozone, we should follow this rule too. User short name should be used in
# native ACL rule, and native ACL check
# is Ozone admin check
# is Volume/Bucket/Key owner check
> Consistently use user's short name in secure mode
> -------------------------------------------------
>
> Key: HDDS-5043
> URL: https://issues.apache.org/jira/browse/HDDS-5043
> Project: Apache Ozone
> Issue Type: Bug
> Reporter: zhengchenyu
> Assignee: zhengchenyu
> Priority: Major
> Labels: pull-request-available
>
> This issue aims to fix the incorrect usage of UGI's getUserName in secure
> mode.
> In my test and search code, I Found we couldn't list volume accurately in
> secure mode.
> (Note: I changed the tittle, some incorrect usage of UGI's getUserName
> doesn't matter. Let's focuse on list volume in secure mode.)
>
> Ozone inherits the Hadoop's user login and management mechanism. There are
> two user types in Hadoop, one is simple user, another is Kerberos user. For
> simple user, it's user name and short user name are identical. For Kerberos
> user, it's user name is Kerberos principla, for example,
> testuser/[email protected], its short name is testuser. After a kerberos
> user login, its mapped user in Hadoop/HDFS is its shortname. Refer to the
> User Identity section of
> [https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html.
>
> |https://hadoop.apache.org/docs/r3.3.1/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html]
>
> So in Ozone, we should follow this rule too. User short name should be used
> in
> # native ACL rule, and native ACL check
> # is Ozone admin check
> # is Volume/Bucket/Key owner check
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
