Emil Kleszcz created HDDS-15620:
-----------------------------------
Summary: Ozone admin read/status commands bypass read-only admin
authorization
Key: HDDS-15620
URL: https://issues.apache.org/jira/browse/HDDS-15620
Project: Apache Ozone
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Emil Kleszcz
In a secure Kerberized Ozone cluster, some {{ozone admin}} read/status commands
can be executed by an authenticated user that is not configured as a full Ozone
administrator and is not a member of the configured read-only administrator
group.
Example configuration:
{code:java}
<property>
<name>ozone.security.enabled</name>
<value>true</value>
</property>
<property>
<name>ozone.acl.enabled</name>
<value>true</value>
</property>
<property>
<name>ozone.acl.authorizer.class</name>
<value>org.apache.hadoop.ozone.security.acl.OzoneNativeAuthorizer</value>
</property>
<property>
<name>ozone.administrators</name>
<value>ozone</value>
</property>
<property>
<name>ozone.readonly.administrators.groups</name>
<value>ozone-readonly-admins</value>
</property>
{code}
The tested user is authenticated with Kerberos and allowed by the
service/protocol ACLs, but is not a full admin and is not a member of
{{{}ozone-readonly-admins{}}}.
These commands succeed for the non-admin user:
{code:java}
ozone admin om roles
ozone admin scm roles
ozone admin datanode list
ozone admin safemode status
{code}
The same user is correctly denied for object access and state-changing admin
operations:
{code:java}
ozone sh key list /user/<other-user>
# PERMISSION_DENIED
ozone sh volume create /test-volume
# PERMISSION_DENIED
ozone admin safemode exit
# Access denied for user <user>. SCM superuser privilege is required.
{code}
So this does not appear to expose full admin privileges. State-changing admin
operations are denied correctly.
>From checking the source code, these read/status paths do not appear to
>perform method-level checks against either _ozone.administrators_ or
{_}ozone.readonly.administrators{_}:
* _ozone admin om roles_
** _GetServiceRolesSubcommand_
** _OzoneManagerProtocol.getServiceList()_
** _OzoneManagerRequestHandler.getServiceList()_
** _OzoneManager.getServiceList()_
* _ozone admin scm roles_
** _GetScmRatisRolesSubcommand_
** _ScmClient.getScmRoles()_
** _SCMClientProtocolServer.getScmInfo()_
* _ozone admin datanode list_
** _ListInfoSubcommand_
** _ScmClient.queryNode(...)_
** _SCMClientProtocolServer.queryNode(...)_
* _ozone admin safemode status_
** _SafeModeCheckSubcommand_
** _ScmClient.inSafeMode()_
** _SCMClientProtocolServer.inSafeMode()_
By contrast, _ozone admin safemode exit_ calls
{_}SCMClientProtocolServer.forceExitSafeMode(){_}, which checks SCM admin
privileges and denies the same user.
I also could not find direct authorization test coverage for these commands.
There are functional tests for some of them, but not tests asserting the
expected behaviour for:
* full admin
* read-only admin
* authenticated non-admin
*Clarification:*
Is this expected behaviour?
If yes, it would be useful to clarify in the documentation that some _ozone
admin_ read/status commands are available to authenticated users admitted by
the service/protocol ACLs, and are not controlled by
_ozone.readonly.administrators*. Ref.
[https://ozone.apache.org/docs/administrator-guide/configuration/security/administrators/#read-only-ozone-administrators]
If not, should these commands be protected by explicit full-admin or
read-only-admin checks?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
