Trino permission control based on an Elasticsearch strategy and device

Abstract

The application discloses a Trino permission control method and device based on an Elasticsearch strategy, which comprises the following steps: pre-configuring an index and a data structure of ES between a business system and Trino, and initializing Trino to connect ES based on a trino-main module; after writing current user permission data on a business side, parsing a TrinoSQL statement to obtain a catalog, a schema, a table and execution user information in the TrinoSQL statement; performing permission verification on the current user based on the catalog, the schema, the table and the execution user information in the obtained TrinoSQL statement; and in the case of passing the verification, packing a trino-main module corresponding to the current user, and performing replacement in tar.gz to complete permission deployment of the current user. The method increases the control on the permissions of all data sources in trino, realizes real-time response to the change of permission data, and realizes more accurate permission verification.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of computers, in particular to a Trino permission control based on an Elasticsearch strategy and an apparatus. BACKGROUND

[0002] Trino is an excellent OLAP query engine, and the Trino philosophy is SQL on Everything, that is, data stored anywhere can be read in a standard SQL manner. Trino itself does not store data, and is a typical MPP framework of storage and calculation separation, and is very suitable for multi-source heterogeneous joint query scenarios.

[0003] In a large-scale Trino cluster, the resource isolation between users and the permission control of users on a catalog / schema / table need to be solved, so as to meet the multi-tenancy of Trino.

[0004] In the prior art, before the name change (PrestoSQL), the Presto permission plug-in is integrated in Ranger 2.0 (https: / / issues.apache.org / jira / browse / RANGER-2395). The Ranger authentication capability is added to the Hive MetaStore server side, and the process of Hive data authentication is sunk to the metadata server side, so that the Trino side does not need to provide authentication capability, and the code invasiveness is less.

[0005] When Trino accesses the MetaStore, the correct client user is passed, and then the MetaStore service receives the Trino call request and sends an authentication request to the Ranger

[0006] In the existing scheme, the Presto permission plug-in has a compatibility problem after the name change of PrestoSQL. The Ranger community has not provided a reasonable solution.

[0007] The Trino implementation of the Ranger authentication controls the strategy of the Hive data source, and the strategy of Trino is not synchronized with the strategy of HiveServer2, which will cause the strategy of the Trino-hive data source to be different from that of HiveServer2.

[0008] The permissions of a relational database (Mysql, Oracle, postgresql, Sqlserver, etc.) cannot be controlled.

[0009] The addition, change and deletion of permission data are relatively cumbersome. SUMMARY

[0010] The embodiment of the application provides a Trino permission control method and device based on an Elasticsearch strategy, to increase the control on the permissions of all data sources in the Trino, realize real-time response to the change of the permission data, and realize more accurate permission verification.

[0011] The embodiment of the application provides a Trino permission control method based on an Elasticsearch strategy, which comprises the following steps:

[0012] The index and data structure of ES between the business system and the Trino are preconfigured, and the Trino is connected to the ES based on the trino-main module;

[0013] After the user permission data is written in the business end, the Trino SQL statement is parsed to obtain the catalog, schema, table and execution user information in the Trino SQL statement;

[0014] The permission verification is performed on the current user based on the catalog, schema, table and execution user information in the obtained Trino SQL statement;

[0015] In the case that the verification is passed, the trino-main module corresponding to the current user is packaged, and the replacement is performed in the tar.gz to complete the permission deployment of the current user.

[0016] Optionally, the catalog in the obtained Trino SQL statement comprises:

[0017] checkCanAccessCatalog: verifying whether the user can access the catalog;

[0018] filterCatalogs: filtering the catalog;

[0019] The schema in the obtained Trino SQL statement comprises:

[0020] checkCanShowSchemas: verifying whether the user can access the schema under the current catalog;

[0021] filterSchemas: filtering the schema allowed to be accessed according to the user;

[0022] The table in the obtained Trino SQL statement comprises:

[0023] filterTables: filter tables with query permissions;

[0024] checkCanInsertIntoTable: check if the table has permission to insert data;

[0025] checkCanDeleteFromTable: check if the table has permission to delete data;

[0026] The execution user information in the obtained Trino SQL statement includes:

[0027] checkCanShowTablesMetadata: check if the table metadata is allowed to be accessed;

[0028] checkCanSelectFromColumns: check if the user has permission to query columns.

[0029] Optionally, the execution permission check for the current user based on the catalog, schema, table, and execution user information in the obtained Trino SQL statement includes:

[0030] Based on the checkCanAccessCatalog, if it is determined that the current user is a superuser, the check is passed, otherwise, based on the ES query dbUserName, catalogName, if the permission exists, the check is passed;

[0031] Based on the filterCatalogs, the query permission of the catalog of the user is checked, if the current user is a superuser, all catalogs are returned, otherwise, all catalogs are traversed, and the permission is checked based on the ES query dbUserName and catalogName, and the returned permission is returned;

[0032] Based on the checkCanShowSchemas, if it is determined that the current user is a superuser, the check is passed, otherwise, based on the ES query dbUserName, if the permission exists, the check is passed;

[0033] Based on the filterSchemas, the query permission of the schema of the user is checked, if the current user is a superuser, all schemaName are returned, otherwise, all schemaName are traversed, and the permission is checked based on the ES query dbUserName, catalogName, and schemaName, and the returned permission is returned;

[0034] Based on the checkCanShowTablesMetadata, query the ES by dbUserName, catalogName, schemaName to see if the user has query permission of the table metadata;

[0035] Based on the filterTables, traverse each SchemaTableName, query the ES to determine whether each table has query permission;

[0036] Based on the checkCanSelectFromColumns, parse CatalogSchemaTableName into catalogName and SchemaTableName objects, and query catalogName, schemaName, tableName, and columnName in the ES to determine whether the column has query permission;

[0037] Based on the checkCanInsertIntoTable, parse catalogName, schemaName, and tableName from CatalogSchemaTableName, and query the ES to determine whether the table has write permission.

[0038] Based on the checkCanDeleteFromTable, parse catalogName, schemaName, and tableName from CatalogSchemaTableName, and query the ES to determine whether there is DELETE_OPERATION_AUTH permission.

[0039] Optionally, after completing the permission deployment of the current user, the Trino permission control method further includes: entering the server and verifying the permission interception condition by using a preset instruction.

[0040] The application embodiment further provides a Trino permission control device based on an Elasticsearch strategy, including a processor configured to:

[0041] Preconfigure the index and data structure of the ES between the business system and the Trino, and initialize the Trino to connect the ES based on the trino-main module;

[0042] After writing the current user permission data on the business side, parse the Trino SQL statement to obtain catalog, schema, table, and execution user information in the Trino SQL statement;

[0043] perform a permission check on the current user based on the obtained catalog, schema, table and execution user information in the Trino SQL statement;

[0044] In the case of passing the check, the trino-main module corresponding to the current user is packaged, and replacement is performed in tar.gz to complete the permission deployment of the current user.

[0045] Optionally, the catalog in the obtained Trino SQL statement includes:

[0046] checkCanAccessCatalog: check whether the user can access the catalog;

[0047] filterCatalogs: filter the catalog;

[0048] The schema in the obtained Trino SQL statement includes:

[0049] checkCanShowSchemas: check whether the user can access the schema under the current catalog;

[0050] filterSchemas: filter the schema allowed to be accessed according to the user;

[0051] The table in the obtained Trino SQL statement includes:

[0052] filterTables: filter the table with query permission;

[0053] checkCanInsertIntoTable: check whether the table has the permission of inserting data;

[0054] checkCanDeleteFromTable: check whether the table has the permission of deleting data;

[0055] The execution user information in the obtained Trino SQL statement includes:

[0056] checkCanShowTablesMetadata: check the table metadata allowed to be accessed;

[0057] checkCanSelectFromColumns: check whether the user has the permission of querying columns.

[0058] Optionally, the processor is specifically configured to:

[0059] Based on the checkCanAccessCatalog, if the current user is a super user, then pass, otherwise, based on ES query dbUserName, catalogName if there is a permission, if there is, then pass the check;

[0060] Based on the filterCatalogs, check the catalog query permission of the user, if the current user is a super user, then return all catalogs, otherwise, traverse all catalogs, and check the permission based on ES by dbUserName and catalogName, and return the permission that meets the requirements;

[0061] Based on the checkCanShowSchemas, if the current user is a super user, then pass, otherwise, based on ES query dbUserName if there is a permission, if there is, then pass the check;

[0062] Based on the filterSchemas, check the schema query permission of the user, if the current user is a super user, then return all schemaName, otherwise, traverse all schemaName, and check the permission based on ES by dbUserName, catalogName, schemaName, and return the permission that meets the requirements;

[0063] Based on the checkCanShowTablesMetadata, query ES by dbUserName, catalogName, schemaName to see if the user has the query permission of table metadata;

[0064] Based on the filterTables, traverse each SchemaTableName, and query ES to determine whether each table has query permission;

[0065] Based on the checkCanSelectFromColumns, parse CatalogSchemaTableName into catalogName and SchemaTableName objects, and query catalogName, schemaName, tableName, and columnName in ES to determine whether the column has query permission;

[0066] Based on the checkCanInsertIntoTable, according to CatalogSchemaTableName, the catalogName, schemaName, and tableName are parsed, and in the case that the table has write permission in ES, the check passes;

[0067] Based on the checkCanDeleteFromTable, according to CatalogSchemaTableName, the catalogName, schemaName, and tableName are parsed, and based on the ES query whether there is a DELETE_OPERATION_AUTH permission.

[0068] Optionally, after completing the permission deployment of the current user, the processor is specifically configured to: enter the server, and verify the permission interception condition by using a preset instruction.

[0069] The embodiment of the application performs permission verification on the current user based on the obtained catalog, schema, table, and execution user information in the Trino SQL statement; in the case that the verification passes, the trino-main module corresponding to the current user is packaged, and replacement is performed in tar.gz to complete the permission deployment of the current user, thereby increasing the control on the permissions of all data sources in trino, realizing real-time response to the change of the permission data, and realizing more accurate permission verification.

[0070] The above description is only a summary of the technical solutions of the application, in order to enable the technical means of the application to be implemented according to the content of the specification, and in order to enable the above and other purposes, characteristics and advantages of the application to be more obvious and easy to understand, the following specific embodiments of the application are described. BRIEF DESCRIPTION OF DRAWINGS

[0071] Various other advantages and benefits will become apparent to those of ordinary skill in the art, upon reading the following detailed description of the preferred embodiments. The accompanying drawings are intended to depict only preferred embodiments of the application, and therefore should not be considered to narrow the scope of the present application in any way. Similarly, it should be appreciated that, where used, the reference numbers in the drawings signify the various embodiments of the application and their equivalents, and in no way limit the scope of the application. In the drawings:

[0072] Figure 1 Basic flowchart of the Trino permission control method of the embodiment of the application;

[0073] Figure 2 General flowchart of the Trino permission control method of the embodiment of the application. DETAILED DESCRIPTION

[0074] Exemplary embodiments of the present disclosure will be described in greater detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it is understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure can be more thoroughly understood, and so that the scope of the present disclosure can be completely conveyed to those skilled in the art.

[0075] Elasticsearch (ES) is a real-time distributed storage, search, and analysis engine. An Elasticsearch cluster has multiple Elasticsearch nodes, and a node is actually a machine running an Elasticsearch process.

[0076] The embodiments of the present application provide a Trino permission control method based on an Elasticsearch strategy, as shown in Figure 1 The method comprises the following steps:

[0077] In step S101, the index and data structure of ES between the business system and Trino are pre-configured, the permission data is updated to ES, and Trino is connected to ES based on the trino-main module. The specific initialization process can include Trino configuring the connection information of ES, introducing the client dependency of ES, initializing the connection to ES in the trino-main module, and writing the client query method of ES.

[0078] In step S102, after the current user permission data is written on the business side, the Trino SQL statement is parsed to obtain the catalog, schema, table, and execution user information in the Trino SQL statement.

[0079] In step S103, the permission of the current user is verified based on the catalog, schema, table, and execution user information in the obtained Trino SQL statement.

[0080] In step S104, if the verification is passed, the trino-main module corresponding to the current user is packaged, and the tar.gz is executed to replace it, so as to complete the permission deployment of the current user. After the deployment is completed, it can be enabled.

[0081] The method of the application loads each data source after the Trino process is started, and connects the ES database. The index structure in the ES has been constrained with the business platform, and when the user performs cross-data source query, the catalog\schema\table in the SQL statement is parsed and the SystemSecurityContext (containing user, group, policy, etc. information) is executed. The permission control class io.trino.security.AccessControl implements each policy filtering method in the subclass io.trino.security.AllowAllAccessControl, captures the user and catalog, schema, table, determines whether the read-write permission of the user meets the requirements through the query elasticsearch, gives the query result and throws the permission exception, recompiles the trino-main and trino-spi modules, replaces the jar package in the source code, and thus the control of the trino permission is realized. Through the method of the application, the permissions of all data sources in the trino are controlled, the real-time response to the change of the permission data is realized, and the more accurate permission verification is realized.

[0082] In some embodiments, the catalog in the obtained Trino SQL statement includes:

[0083] checkCanAccessCatalog: checking whether the user can access the catalog;

[0084] filterCatalogs: filtering the catalog;

[0085] The schema in the obtained Trino SQL statement includes:

[0086] checkCanShowSchemas: checking whether the user can access the schema under the current catalog;

[0087] filterSchemas: filtering the schema allowed to be accessed according to the user;

[0088] The table in the obtained Trino SQL statement includes:

[0089] filterTables: filtering the table with query permission;

[0090] checkCanInsertIntoTable: checking whether the table has the permission of inserting data;

[0091] checkCanDeleteFromTable: check if the table has permission to delete data;

[0092] The execution user information in the obtained Trino SQL statement includes:

[0093] checkCanShowTablesMetadata: check if the table metadata is allowed to be accessed;

[0094] checkCanSelectFromColumns: check if the user has the permission to query the column.

[0095] In some embodiments, the permission check is performed for the current user based on the catalog, schema, table, and execution user information in the obtained Trino SQL statement, as shown in the following code: Figure 2 The method of the subclass io.trino.security.AllowAllAccessControl of io.trino.security.AccessControl includes:

[0096] Based on the checkCanAccessCatalog, if it is determined that the current user is a superuser, the check is passed, otherwise, based on the ES query dbUserName, catalogName, if the permission exists, the check is passed, otherwise, an exception of "user has no permission to access catalog" is thrown.

[0097] Based on the filterCatalogs, the query permission of the catalog of the user is checked, if the current user is a superuser, all catalogs are returned, otherwise, all catalogs are traversed, and the permission is checked based on the ES through dbUserName and catalogName, and the permissions that meet the conditions are returned. The catalog is filtered, which is generally generated by monitoring the "show catalogs;" such SQL statement, and checking the query permission of the catalog of the user. The input parameters are user information Identity and a set of catalogs.

[0098] Based on the checkCanShowSchemas, if it is determined that the current user is a superuser, the check is passed, otherwise, based on the ES query dbUserName, if the permission exists, the check is passed, otherwise, an exception of "user has no permission to access catalog under schemas" is thrown.

[0099] Based on the filterSchemas, check the query permission of the schema of the user, if the current user is a super user, return all schemaName, otherwise traverse all schemaName, check the permission based on ES through dbUserName, catalogName, schemaName, and return the permission that meets the requirements. Generally, it is generated due to monitoring the sql statement such as "show schemas from catalog;", and checking which schema the user has query permission. The input parameters are user information Identity, catalogName, and a set of schemaName.

[0100] Based on the checkCanShowTablesMetadata, query ES through dbUserName, catalogName, and schemaName to see if the user has query permission of table metadata.

[0101] Based on the filterTables, traverse each SchemaTableName, query ES to determine whether each table has query permission. The input parameters are Identity, catalogName, Set <schematablename>.

[0102] Based on the checkCanSelectFromColumns, the input parameters are Identity, CatalogSchemaTableName, and columnName set. First, parse CatalogSchemaTableName into catalogName and SchemaTableName objects, and then query catalogName, schemaName, tableName, and columnName in ES to determine whether the query permission of the column is owned. Through this method, the permission can be controlled to the column.

[0103] Based on the checkCanInsertIntoTable, according to CatalogSchemaTableName, parse catalogName, schemaName, and tableName. ES stores WRITE_OPERATION_AUTH bound to the table. The write permission of the table can be queried in ES. If the write permission exists, the check passes, otherwise, an exception is thrown.

[0104] Based on the checkCanDeleteFromTable, according to CatalogSchemaTableName, parse catalogName, schemaName, and tableName. Based on ES query whether there is DELETE_OPERATION_AUTH permission.

[0105] In some embodiments, after completing the permission deployment of the current user, the Trino permission control method further includes: entering the server, and verifying the permission interception condition by using a preset instruction. For example, a command such as. / trino-server ip:8660-user username can be used to verify the permission interception condition.

[0106] The method of the present application can increase the control of the permissions of all data sources in trino, control from the three-layer structure of catalog, schema, and table, and also can customize the permission business (such as write, read), and the change of the permission data is also a real-time response, which is more accurate for permission verification.

[0107] The embodiment of the present application also provides a Trino permission control device based on an Elasticsearch strategy, including a processor configured to:

[0108] Index and data structure of ES between the pre-configuration business system and Trino are configured, and the Trino is connected to the ES based on the trino-main module;

[0109] After the current user permission data is written at the business end, the Trino SQL statement is parsed to obtain catalog, schema, table and execution user information in the Trino SQL statement;

[0110] Based on the obtained catalog, schema, table and execution user information in the Trino SQL statement, the current user is checked for execution permission;

[0111] In the case of passing the check, the trino-main module corresponding to the current user is packaged, and replacement is performed in tar.gz to complete the permission deployment of the current user.

[0112] In some embodiments, the obtained catalog in the Trino SQL statement includes:

[0113] checkCanAccessCatalog: Check whether the user can access the catalog;

[0114] filterCatalogs: Filter the catalog;

[0115] The obtained schema in the Trino SQL statement includes:

[0116] checkCanShowSchemas: Check whether the user can access the schema under the current catalog;

[0117] filterSchemas: Filter the schema allowed to be accessed according to the user;

[0118] The obtained table in the Trino SQL statement includes:

[0119] filterTables: Filter the table with query permission;

[0120] checkCanInsertIntoTable: Check whether the table has the permission of inserting data;

[0121] checkCanDeleteFromTable: Check whether the table has the permission of deleting data;

[0122] The obtained execution user information in the Trino SQL statement includes:

[0123] checkCanShowTablesMetadata: check if the user has permission to access table metadata;

[0124] checkCanSelectFromColumns: check if the user has permission to query columns.

[0125] In some embodiments, the processor is specifically configured to:

[0126] based on the checkCanAccessCatalog, if it is determined that the current user is a super user, then the check passes, otherwise, based on an ES query of dbUserName, catalogName, if there is permission, then the check passes;

[0127] based on the filterCatalogs, check the query permission of the catalog of the user, if the current user is a super user, then return all catalog, otherwise, traverse all catalog, check the permission based on ES piece by piece through dbUserName and catalogName, and return the permission that meets the requirements;

[0128] based on the checkCanShowSchemas, if it is determined that the current user is a super user, then the check passes, otherwise, based on an ES query of dbUserName, if there is permission, then the check passes;

[0129] based on the filterSchemas, check the query permission of the schema of the user, if the current user is a super user, then return all schemaName, otherwise, traverse all schemaName, check the permission based on ES piece by piece through dbUserName, catalogName, and schemaName, and return the permission that meets the requirements;

[0130] based on the checkCanShowTablesMetadata, query ES through dbUserName, catalogName, and schemaName to see if the user has query permission of table metadata;

[0131] based on the filterTables, traverse each SchemaTableName, and query ES to determine if each table has query permission;

[0132] Based on the checkCanSelectFromColumns, the CatalogSchemaTableName is parsed into catalogName and SchemaTableName objects, and catalogName, schemaName, tableName, and columnName are queried in the ES to determine whether the query permission of the column is owned;

[0133] Based on the checkCanInsertIntoTable, the catalogName, schemaName, and tableName are parsed according to the CatalogSchemaTableName, and the ES is queried to determine whether the table has the write permission, and the check is passed.

[0134] Based on the checkCanDeleteFromTable, the catalogName, schemaName, and tableName are parsed according to the CatalogSchemaTableName, and whether the DELETE_OPERATION_AUTH permission is queried based on the ES.

[0135] In some embodiments, after the permission deployment of the current user is completed, the processor is specifically configured to: enter the server, and verify the permission interception condition by using a preset instruction.

[0136] It should be noted that in this document, the terms "comprising", "including", or any other variant thereof are intended to cover non-exclusive inclusions, so that a process, method, article, or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or further includes elements inherent to such a process, method, article, or device. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of other identical elements in the process, method, article, or device that includes the element.

[0137] The above-mentioned sequence number of the embodiments of the present application is only for description, and does not represent the advantages and disadvantages of the embodiments.

[0138] Through the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned example methods can be realized by means of software and a necessary general hardware platform, and of course, can also be realized by hardware, but in many cases, the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product in essence or in the form of a part that contributes to the prior art. The computer software product is stored in a storage medium (such as a ROM / RAM, a magnetic disk, or an optical disk) and includes a plurality of instructions for causing a terminal (which can be a mobile phone, a computer, a server, or a network device) to execute the methods described in the various embodiments of the present application.

[0139] The embodiments of the present application are described above in combination with the drawings, but the present application is not limited to the specific embodiments described above, and the specific embodiments described above are merely illustrative rather than limiting. Those of ordinary skill in the art can make many forms under the inspiration of the present application without departing from the scope of the present application and the scope protected by the claims.< / schematablename>

Claims

1. A Trino access control method based on Elasticsearch strategies, characterized in that, include: Pre-configure the index and data structure of Elasticsearch between the business system and Trino, and initialize the Trino connection to Elasticsearch based on the trino-main module; After writing the current user's permission data on the business side, the Trino SQL statement is parsed to obtain the catalog, schema, table, and execution user information in the Trino SQL statement. The current user's execution permissions are verified based on the catalog, schema, table, and execution user information obtained from the Trino SQL statement. If the verification passes, package the trino-main module corresponding to the current user and replace it in tar.gz to complete the deployment of permissions for the current user; The catalog in the obtained Trino SQL statements includes: checkCanAccessCatalog: Verifies whether a user can access the catalog. filterCatalogs: Filter catalogs; The schemas in the obtained Trino SQL statements include: checkCanShowSchemas: Verifies whether a user can access the schema under the current catalog; filterSchemas: Filters allowed schemas based on user; The tables in the obtained Trino SQL statements include: filterTables: Filters tables that have query permissions; checkCanInsertIntoTable: Checks whether the table has permission to insert data; checkCanDeleteFromTable: Checks if the table has permission to delete data; The execution user information obtained from the Trino SQL statements includes: checkCanShowTablesMetadata: Verifies the table metadata that is allowed to be accessed; checkCanSelectFromColumns: Checks whether the user has permission to select columns; The execution permission verification for the current user based on the catalog, schema, table, and execution user information in the obtained Trino SQL statement includes: Based on checkCanAccessCatalog, if it is determined that the current user is a super user, the verification is successful; otherwise, the ES query is used to check whether dbUserName and catalogName have permissions. If they do, the verification is successful. Based on the filterCatalogs, the user's catalog query permissions are verified. If the current user is a super user, all catalogs are returned; otherwise, all catalogs are traversed, and permissions are verified one by one based on Elasticsearch using dbUserName and catalogName, and the matching permissions are returned. Based on the checkCanShowSchemas, if it is determined that the current user is a super user, the verification is successful; otherwise, the dbUserName is queried based on ES to see if it has permissions. If it does, the verification is successful. Based on the filterSchemas, the user's schema query permissions are verified. If the current user is a super user, all schemaNames are returned; otherwise, all schemaNames are traversed, and permissions are verified for each schemaName based on ES using dbUserName, catalogName, and schemaName. The permissions that match are returned. Based on the checkCanShowTablesMetadata, query Elasticsearch using dbUserName, catalogName, and schemaName to check if the user has permission to query table metadata. Based on the filterTables, iterate through each SchemaTableName and query Elasticsearch to determine whether each table has query permissions; Based on the checkCanSelectFromColumns, CatalogSchemaTableName is parsed into catalogName and SchemaTableName objects. In Elasticsearch, catalogName, schemaName, tableName, and columnName are queried to determine whether the user has query permissions for that column. Based on the checkCanInsertIntoTable, the catalogName, schemaName, and tableName are parsed from the CatalogSchemaTableName. If the table in Elasticsearch has write permissions, the verification passes. Based on the checkCanDeleteFromTable, the catalogName, schemaName, and tableName are parsed from the CatalogSchemaTableName, and an Elasticsearch query is performed to determine if the user has the DELETE_OPERATION_AUTH permission.

2. The Trino access control method based on Elasticsearch strategy as described in claim 1, characterized in that, After completing the permission deployment for the current user, the Trino permission control method further includes: accessing the server and using preset instructions to verify permission interception.

3. A Trino access control device based on Elasticsearch policies, characterized in that, Including the processor, which is configured as follows: Pre-configure the index and data structure of Elasticsearch between the business system and Trino, and initialize the Trino connection to Elasticsearch based on the trino-main module; After writing the current user's permission data on the business side, the Trino SQL statement is parsed to obtain the catalog, schema, table, and execution user information in the Trino SQL statement. The current user's execution permissions are verified based on the catalog, schema, table, and execution user information obtained from the Trino SQL statement. If the verification passes, package the trino-main module corresponding to the current user and replace it in tar.gz to complete the deployment of permissions for the current user; The catalog in the obtained Trino SQL statements includes: checkCanAccessCatalog: Verifies whether a user can access the catalog. filterCatalogs: Filter catalogs; The schemas in the obtained Trino SQL statements include: checkCanShowSchemas: Verifies whether a user can access the schema under the current catalog; filterSchemas: Filters allowed schemas based on user; The tables in the obtained Trino SQL statements include: filterTables: Filters tables that have query permissions; checkCanInsertIntoTable: Checks whether the table has permission to insert data; checkCanDeleteFromTable: Checks if the table has permission to delete data; The execution user information obtained from the Trino SQL statements includes: checkCanShowTablesMetadata: Verifies the table metadata that is allowed to be accessed; checkCanSelectFromColumns: Checks whether the user has permission to select columns; The processor is specifically configured as follows: Based on checkCanAccessCatalog, if it is determined that the current user is a super user, the verification is successful; otherwise, the ES query is used to check whether dbUserName and catalogName have permissions. If they do, the verification is successful. Based on the filterCatalogs, the user's catalog query permissions are verified. If the current user is a super user, all catalogs are returned; otherwise, all catalogs are traversed, and permissions are verified one by one based on Elasticsearch using dbUserName and catalogName, and the matching permissions are returned. Based on the checkCanShowSchemas, if it is determined that the current user is a super user, the verification is successful; otherwise, the dbUserName is queried based on ES to see if it has permissions. If it does, the verification is successful. Based on the filterSchemas, the user's schema query permissions are verified. If the current user is a super user, all schemaNames are returned; otherwise, all schemaNames are traversed, and permissions are verified for each schemaName based on ES using dbUserName, catalogName, and schemaName. The permissions that match are returned. Based on the checkCanShowTablesMetadata, query Elasticsearch using dbUserName, catalogName, and schemaName to check if the user has permission to query table metadata. Based on the filterTables, iterate through each SchemaTableName and query Elasticsearch to determine whether each table has query permissions; Based on the checkCanSelectFromColumns, CatalogSchemaTableName is parsed into catalogName and SchemaTableName objects. In Elasticsearch, catalogName, schemaName, tableName, and columnName are queried to determine whether the user has query permissions for that column. Based on the checkCanInsertIntoTable, the catalogName, schemaName, and tableName are parsed from the CatalogSchemaTableName. If the table in Elasticsearch has write permissions, the verification passes. Based on the checkCanDeleteFromTable, the catalogName, schemaName, and tableName are parsed from the CatalogSchemaTableName, and an Elasticsearch query is performed to determine if the user has the DELETE_OPERATION_AUTH permission.

4. The Trino access control device based on Elasticsearch policy as described in claim 3, characterized in that, After completing the deployment of permissions for the current user, the processor is specifically configured to: enter the server and use preset instructions to verify the permission interception status.

Images