[ 
https://issues.apache.org/jira/browse/RANGER-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17512701#comment-17512701
 ] 

Xuze Yang commented on RANGER-3685:
-----------------------------------

In addition to the introduction of configuration items, we can also decide 
according to the number of objects (size(objs)), if the number is less than a 
set value, record the audit log. Otherwise, read the value of the configuration 
item to decide whether to record the audit log or not
{code:java}
public List<HivePrivilegeObject> filterListCmdObjects(List<HivePrivilegeObject> 
objs,
                                         HiveAuthzContext          
context){code}
Is this plan feasible? Any suggestions are welcome.

> hive 'show' sql produces excessive audit log
> --------------------------------------------
>
>                 Key: RANGER-3685
>                 URL: https://issues.apache.org/jira/browse/RANGER-3685
>             Project: Ranger
>          Issue Type: Improvement
>          Components: audit
>    Affects Versions: 2.1.0
>            Reporter: Xuze Yang
>            Priority: Major
>
> Since ranger2.1.0. For "show databases", user needs any permission on 
> Database to get authorized. RangerHiveAuthorizer.filterListCmdObjects() is 
> implemented to filter out the database which user don't have access to. 
> This is a good implementation, but a problem comes with it:the method will 
> record an audit log for each database(each table for "show tables"). In our 
> production environment, There are 80,000 tables under a database of hive. A 
> show tables operation will generate 80001(The extra one is the verification 
> of USE permissions) audit logs. Unfortunately, our customers will frequently 
> call the show tables operation.
> This brings up two problems: 
>  # Valuable audit logs are flooded
>  # Take up a lot of storage resources
> For problem.2, such a scenario has occurred in our environment: our audit log 
> destination is down. All audit logs are spooled in disk files, several days 
> later, the size of the disk file exceeded 800G, causing other components to 
> fail to provide services normally.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to