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

Vinayakumar B commented on HDFS-9395:
-------------------------------------

Thanks [~kshukla] for the update.

2 comments for latest patch.
1. {{getAclStatus}}, from Chris' suggestion above, need to preserve 
auditlogging for successfull operation. But its also necessary to log Access 
failed operations, similar to {{checkAccess}}.

2. {{setErasureCodingPolicy}} now missing access failed audit log.

> Make HDFS audit logging consistant
> ----------------------------------
>
>                 Key: HDFS-9395
>                 URL: https://issues.apache.org/jira/browse/HDFS-9395
>             Project: Hadoop HDFS
>          Issue Type: Bug
>            Reporter: Kihwal Lee
>            Assignee: Kuhu Shukla
>         Attachments: HDFS-9395.001.patch, HDFS-9395.002.patch, 
> HDFS-9395.003.patch, HDFS-9395.004.patch, HDFS-9395.005.patch, 
> HDFS-9395.006.patch
>
>
> So, the big question here is what should go in the audit log? All failures, 
> or just "permission denied" failures? Or, to put it a different way, if 
> someone attempts to do something and it fails because a file doesn't exist, 
> is that worth an audit log entry?
> We are currently inconsistent on this point. For example, concat, 
> getContentSummary, addCacheDirective, and setErasureEncodingPolicy create an 
> audit log entry for all failures, but setOwner, delete, and setAclEntries 
> attempt to only create an entry for AccessControlException-based failures. 
> There are a few operations, like allowSnapshot, disallowSnapshot, and 
> startRollingUpgrade that never create audit log failure entries at all. They 
> simply log nothing for any failure, and log success for a successful 
> operation.
> So to summarize, different HDFS operations currently fall into 3 categories:
> 1. audit-log all failures
> 2. audit-log only AccessControlException failures
> 3. never audit-log failures
> Which category is right?  And how can we fix the inconsistency



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to