[
https://issues.apache.org/jira/browse/HDFS-9395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15129094#comment-15129094
]
Colin Patrick McCabe edited comment on HDFS-9395 at 2/2/16 9:46 PM:
--------------------------------------------------------------------
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
Category #3 seems like a clear violation of what people expect out of the audit
log, since it will leave out all the unsuccessful attempts to do some
privileged operation. So perhaps the category #3 operations are clearly buggy.
The question then becomes, is the category #1 or #2 interpretation correct?
One potential issue I see with category #2 is that if there is some failure
that ultimately is permissions-related, but which fails to generate the
specific {{AccessControlException}} subclass of exception, we will miss it. So
category #1 operations are more robust against changes in the exception
handling.
was (Author: cmccabe):
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, operations fall into 3 categories:
1. audit-log *all* failures
2. audit-log only {{AccessControlException}} failures
3. *never* audit-log failures
Category #3 seems like a clear violation of what people expect out of the audit
log, since it will leave out all the unsuccessful attempts to do some
privileged operation. So perhaps the category #3 operations are clearly buggy.
The question then becomes, is the category #1 or #2 interpretation correct?
One potential issue I see with category #2 is that if there is some failure
that ultimately is permissions-related, but which fails to generate the
specific {{AccessControlException}} subclass of exception, we will miss it. So
category #1 operations are more robust against changes in the exception
handling.
> 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
>
>
> Audit logging is in the fainally block along with the lock unlocking, so it
> is always logged as success even for cases like FileNotFoundException is
> thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
