[
https://issues.apache.org/jira/browse/HADOOP-16251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16831936#comment-16831936
]
Aaron Fabbri edited comment on HADOOP-16251 at 5/9/19 1:04 AM:
---------------------------------------------------------------
Thanks for the patch [~DanielZhou]. We really appreciate you adding extra test
coverage for cloud filesystems (ABFS)
Couple of questions about the patch:
{noformat}
@Ignore("There shouldn't be permission check for getFileInfo")
public void
testListStatusThrowsExceptionForUnreadableDir() {{noformat}
Since this is a listing test, wouldn't the READ | EXECUTE checks still be valid?
*EDIT: Nevermind on the getFileInfo comment below.. I confused HA check with
permission check there.*
Also, I'm surprised about getFileStatus / getFileInfo being listed as "N/A" for
permission checks. It seems wrong from security perspective and -also looking
at the code doesn't seem to be the case see this
[link|https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java#L3202-L3204]:-
{noformat}
HdfsFileStatus getFileInfo(final String src, boolean resolveLink,
boolean needLocation, boolean needBlockToken) throws IOException {
// if the client requests block tokens, then it can read data blocks
// and should appear in the audit log as if getBlockLocations had been
// called
final String operationName = needBlockToken ? "open" : "getfileinfo";
checkOperation(OperationCategory.READ);
HdfsFileStatus stat = null;
final FSPermissionChecker pc = getPermissionChecker();
readLock();
try {
checkOperation(OperationCategory.READ);
stat = FSDirStatAndListingOp.getFileInfo({noformat}
-Looks like the HDFS Permissions doc is incorrect, no?-
was (Author: fabbri):
Thanks for the patch [~DanielZhou]. We really appreciate you adding extra test
coverage for cloud filesystems (ABFS)
Couple of questions about the patch:
{noformat}
@Ignore("There shouldn't be permission check for getFileInfo")
public void
testListStatusThrowsExceptionForUnreadableDir() {{noformat}
Since this is a listing test, wouldn't the READ | EXECUTE checks still be valid?
Also, I'm surprised about getFileStatus / getFileInfo being listed as "N/A" for
permission checks. It seems wrong from security perspective and also looking at
the code doesn't seem to be the case - see this
[link|https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java#L3202-L3204]:
{noformat}
HdfsFileStatus getFileInfo(final String src, boolean resolveLink,
boolean needLocation, boolean needBlockToken) throws IOException {
// if the client requests block tokens, then it can read data blocks
// and should appear in the audit log as if getBlockLocations had been
// called
final String operationName = needBlockToken ? "open" : "getfileinfo";
checkOperation(OperationCategory.READ);
HdfsFileStatus stat = null;
final FSPermissionChecker pc = getPermissionChecker();
readLock();
try {
checkOperation(OperationCategory.READ);
stat = FSDirStatAndListingOp.getFileInfo({noformat}
Looks like the HDFS Permissions doc is incorrect, no?
> ABFS: add FSMainOperationsBaseTest
> ----------------------------------
>
> Key: HADOOP-16251
> URL: https://issues.apache.org/jira/browse/HADOOP-16251
> Project: Hadoop Common
> Issue Type: Sub-task
> Components: fs/azure
> Affects Versions: 3.2.0
> Reporter: Da Zhou
> Assignee: Da Zhou
> Priority: Major
>
> Just happened to see
> "hadoop/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/fs/FSMainOperationsBaseTest.java",
> ABFS could inherit this test to increase its test coverage.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
