hdygxsj commented on code in PR #6842: URL: https://github.com/apache/gravitino/pull/6842#discussion_r2049807809
########## server-common/src/main/java/org/apache/gravitino/server/authorization/GravitinoAuthorizer.java: ########## @@ -0,0 +1,43 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * http://www.apache.org/licenses/LICENSE-2.0 + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +package org.apache.gravitino.server.authorization; + +import org.apache.gravitino.MetadataObject; +import org.apache.gravitino.authorization.Privilege; + +/** Used for metadata authorization. */ +public interface GravitinoAuthorizer { + + /** + * After instantiating the GravitinoAuthorizer, execute the initialize method to perform a series + * of initialization operations, such as loading privilege policies and so on. + */ + void initialize(); + + /** + * Perform authorization and return the authorization result. + * + * @param userId the user id in use_meta table + * @param metadataType for example, CATALOG, SCHEMA,TABLE, etc. + * @param metadataId the metadata id. + * @param privilege for example, CREATE_CATALOG, CREATE_TABLE, etc. + * @return authorization result. + */ + boolean authorize( Review Comment: > Sometimes we may have to have some permissions **implied** when appropriate. Think about this, is it possible/valid for a user to have `SELECT_TABLE` permission without having a `USE_SCHEMA` or `USE_CATALOG` permission? When I say I'm in Tokyo, you won't ask me if I'm in Japan or if I'm in Asia, right? > > When granting/revoking permissions, we may need to ensure that the permissions are valid. When we say a user can `SELECT_TABLE`, we auto-magically grant the `USE_SCHEMA` and `USE_CATALOG` permissions, since they can be inferred easily. Unless `USE_SCHEMA`/`USE_CATALOG` has some extra usage scenarios, when we revoke all table-level permissions, we revoke the schema/catalog level rights as well. > > Then, when we perform authorization checks, we only check the target operation, e.g. `SELECT_TABLE`. We don't check the schema/catalog level permissions. Authorization checks are way more frequent than the grant/revoke operations. > > This is my 2 cents. According to the previous discussion, USE_SCHEMA means having permissions for all tables under the schema, while USE_TABLE means having permissions for a single table. What do you think? @xunliu -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
