Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.0.0-alpha
-
None
-
Reviewed
Description
Access via WebHdfs does not result in audit log entries. It should.
% 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"}}
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.
% 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
This happens because DatanodeWebHdfsMethods#get uses DFSClient#open thereby triggering the existing logAuditEvent code.