[
https://issues.apache.org/jira/browse/HDFS-9395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131106#comment-15131106
]
Colin Patrick McCabe commented on HDFS-9395:
--------------------------------------------
bq. My position is #2. The audit log should be a record of successful or
unauthorized access to data - not a debug record of every attempted operation.
The reduced SNR of already monstrous logs and the performance penalty (it's
already extremely high) of logging unsuccessful operations generated by
polling, globbing, file not found, rename targets existing, etc is of no value
to me.
Fair enough. The fact that the audit log line contains {{allowed=false}} on
failure is also a strong suggestion that #2 is the original intention of the
audit log. Like I said earlier, I haven't managed to find any documentation
anywhere about this, though.
bq. I see your concern. I'm not aware of any existing issues involving non-ACE
and I've been in the code a lot lately for performance work. Hypothetical
future bugs is not compelling enough to cripple performance. If anyone feels
strongly, it must be a config option that imposes no penalty when off.
One thing that helps a lot is that most (all?) places use
{{FSPermissionChecker}} to check permissions, rather than rolling their own
permission check code.
If everyone agrees, then we should create a patch which fixes all the
operations to log {{allowed=false}} only when there is a permission denied
error, {{allowed=true}} only when the operation succeeds, and nothing otherwise.
> HDFS operations vary widely in which failures they put in the audit log and
> which they leave out
> ------------------------------------------------------------------------------------------------
>
> 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
>
>
> 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)
