[
https://issues.apache.org/jira/browse/HDDS-15620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18090143#comment-18090143
]
Attila Doroszlai commented on HDDS-15620:
-----------------------------------------
I think this is expected behavior. Read-only admins (added in HDDS-8454) are
users/groups who can read all users' objects, but not change them. {{ozone
admin}} groups operational commands, not necessarily restricted to
administrators.
CC [~Sammi] [~z-bb]
> 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
> Priority: Major
>
> 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&lt;/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]
