[
https://issues.apache.org/jira/browse/HDFS-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400053#comment-13400053
]
Eli Collins commented on HDFS-3535:
-----------------------------------
Looks good Andy.
The one audit log that doesn't have a corresponding log for failure is
logFsckEvent, though given that we get the ugi from the request it seems like
that case could result in an ACE as well right?
Style nits:
- Let's use fooInternal vs fooInt to match the existing "fooInternal" methods
- In logAuditEvent I'd rename "succeeded" to "allowed" to match the log and
since we don't differentiate between succeeded and allowed, ie we're not
logging things that didn't succeed (eg IOE), just ones that weren't allowed
(ACE)
Per Colin, what do you think about (in a separate change) moving the two checks
inside logAuditEvent, eg
{code}
logAuditEvent() {
if (!auditLog.isInfoEnabled() || !isExternalInvocation()) {
return;
}
..
}
{code}
Normally the checks are used before the method invocation if we're doing
expensive things to create the args (eg lots of string concatenation) not to
save the cost of the method invocation. Doesn't look like that's the case here
(we're not constructing args) so we could just call logAuditEvent directly
everywhere.
> audit logging should log denied accesses as well as permitted ones
> ------------------------------------------------------------------
>
> Key: HDFS-3535
> URL: https://issues.apache.org/jira/browse/HDFS-3535
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: name-node
> Affects Versions: 2.0.0-alpha
> Reporter: Andy Isaacson
> Assignee: Andy Isaacson
> Attachments: hdfs-3535-1.txt, hdfs-3535.txt
>
>
> FSNamesystem.java logs an audit log entry when a user successfully accesses
> the filesystem:
> {code}
> logAuditEvent(UserGroupInformation.getLoginUser(),
> Server.getRemoteIp(),
> "concat", Arrays.toString(srcs), target, resultingStat);
> {code}
> but there is no similar log when a user attempts to access the filesystem and
> is denied due to permissions. Competing systems do provide such logging of
> denied access attempts; we should too.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
