hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Collins (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-3733) audit logging must cover WebHdfs access
Date Mon, 20 Aug 2012 20:43:38 GMT

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

Eli Collins commented on HDFS-3733:
-----------------------------------

Overall approach makes sense.

- s/CurClient/curClient/
- Use {@link..} to refer to a.h.ipc.Server#isRpcInvocation
- isWebHdfsInvocation returns true if client != null, and client is intialized with getClientMachine
which can return non-null values in the non-webhdfs case, doesn't this imply isWebHdfsInvocation
might return true even if the invocation is not for webhdfs?
- getRemoteIp should not just return NamenodeWebHdfsMethods#getRemoteAddress because it returns
null in the non-webhdfs case even though Server.getRemoteAddress() has a value, ie we're losing
the remote IP for the non-webhdfs case
- Looks like NamenodeWebHdfsMethods#setRemoteAddress is only used by the tests, can we remove
it?
- Please add a TestAuditLogs test that covers access via Hftp so we make sure we're not just
doing something webhdfs specific
                
> audit logging must cover WebHdfs access
> ---------------------------------------
>
>                 Key: HDFS-3733
>                 URL: https://issues.apache.org/jira/browse/HDFS-3733
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: webhdfs
>    Affects Versions: 2.0.0-alpha
>            Reporter: Andy Isaacson
>            Assignee: Andy Isaacson
>         Attachments: hdfs-3733.txt
>
>
> Access via WebHdfs does not result in audit log entries.  It should.
> {noformat}
> % curl "http://nn1:50070/webhdfs/v1/user/adi/hello.txt?op=GETFILESTATUS"
> {"FileStatus":{"accessTime":1343351432395,"blockSize":134217728,"group":"supergroup","length":12,"modificationTime":1342808158399,"owner":"adi","pathSuffix":"","permission":"644","replication":1,"type":"FILE"}}
> {noformat}
> and observe that no audit log entry is generated.
> Interestingly, OPEN requests do not generate audit log entries when the NN generates
the redirect, but do generate audit log entries when the second phase against the DN is executed.
> {noformat}
> % curl -v 'http://nn1:50070/webhdfs/v1/user/adi/hello.txt?op=OPEN'
> ...
> < HTTP/1.1 307 TEMPORARY_REDIRECT
> < Location: http://dn01:50075/webhdfs/v1/user/adi/hello.txt?op=OPEN&namenoderpcaddress=nn1:8020&offset=0
> ...
> % curl -v 'http://dn01:50075/webhdfs/v1/user/adi/hello.txt?op=OPEN&namenoderpcaddress=nn1:8020'
> ...
> < HTTP/1.1 200 OK
> < Content-Type: application/octet-stream
> < Content-Length: 12
> < Server: Jetty(6.1.26.cloudera.1)
> < 
> hello world
> {noformat}
> This happens because {{DatanodeWebHdfsMethods#get}} uses {{DFSClient#open}} thereby triggering
the existing {{logAuditEvent}} code.

--
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

        

Mime
View raw message