[
https://issues.apache.org/jira/browse/HDFS-8246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14578122#comment-14578122
]
Colin Patrick McCabe commented on HDFS-8246:
--------------------------------------------
I think this API should be accessible to everyone, not just admins. It can
help eliminate race conditions.
Let's say you have some daemon that runs with superuser permissions that is
trying to verify that some user U has permission to access /a/b. Then you have
an access pattern like this:
1. daemon checks /a to ensure U has permissions to access it
2. daemon checks /a/b
A malicious user might be able to insert a step 1a.
1a. malicious user moves /a to /a2 and moves /something-else to /a
Then the malicious user would get access to /something-else/b even if he
doesn't have access to /something-else.
There are a lot of scenarios you can set up like this. Any time you have a
check of a path, followed by a use of that path, there can be a race condition
if you are not refering to inodes by number.
bq. What should it return if a block belong to multiple files (current file and
snapshotted files, or hard linked files when we support hard link in the
future)?
Then I think it should return multiple paths, including some to snapshot
directories.
> Get HDFS file name based on block pool id and block id
> ------------------------------------------------------
>
> Key: HDFS-8246
> URL: https://issues.apache.org/jira/browse/HDFS-8246
> Project: Hadoop HDFS
> Issue Type: New Feature
> Components: HDFS, hdfs-client, namenode
> Reporter: feng xu
> Assignee: feng xu
> Labels: BB2015-05-TBR
> Attachments: HDFS-8246.0.patch
>
>
> This feature provides HDFS shell command and C/Java API to retrieve HDFS file
> name based on block pool id and block id.
> 1. The Java API in class DistributedFileSystem
> public String getFileName(String poolId, long blockId) throws IOException
> 2. The C API in hdfs.c
> char* hdfsGetFileName(hdfsFS fs, const char* poolId, int64_t blockId)
> 3. The HDFS shell command
> hdfs dfs [generic options] -fn <poolId> <blockId>
> This feature is useful if you have HDFS block file name in local file system
> and want to find out the related HDFS file name in HDFS name space
> (http://stackoverflow.com/questions/10881449/how-to-find-file-from-blockname-in-hdfs-hadoop).
> Each HDFS block file name in local file system contains both block pool id
> and block id, for sample HDFS block file name
> /hdfs/1/hadoop/hdfs/data/current/BP-97622798-10.3.11.84-1428081035160/current/finalized/subdir0/subdir0/blk_1073741825,
> the block pool id is BP-97622798-10.3.11.84-1428081035160 and the block id
> is 1073741825. The block pool id is uniquely related to a HDFS name
> node/name space, and the block id is uniquely related to a HDFS file within
> a HDFS name node/name space, so the combination of block pool id and a block
> id is uniquely related a HDFS file name.
> The shell command and C/Java API do not map the block pool id to name node,
> so it’s user’s responsibility to talk to the correct name node in federation
> environment that has multiple name nodes. The block pool id is used by name
> node to check if the user is talking with the correct name node.
> The implementation is straightforward. The client request to get HDFS file
> name reaches the new method String getFileName(String poolId, long blockId)
> in FSNamesystem in name node through RPC, and the new method does the
> followings,
> (1) Validate the block pool id.
> (2) Create Block based on the block id.
> (3) Get BlockInfoContiguous from Block.
> (4) Get BlockCollection from BlockInfoContiguous.
> (5) Get file name from BlockCollection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
