hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject understanding HDFS permissions, umasks and the tests thereof
Date Tue, 21 Jan 2014 15:44:09 GMT
Having noticed my code isn't creating directories that are writeable in
mkdirs() unless I set it after, I went to look at the
FileSystemContractBaseTest to see what happens there

  public void testMkdirsWithUmask() throws Exception {
    if (fs.getScheme().equals("s3") || fs.getScheme().equals("s3n")) {
      // skip permission tests for S3FileSystem until HDFS-1333 is fixed.
      return;
    }
    Configuration conf = fs.getConf();
    String oldUmask =
conf.get(CommonConfigurationKeys.FS_PERMISSIONS_UMASK_KEY);
    try {
      conf.set(CommonConfigurationKeys.FS_PERMISSIONS_UMASK_KEY,
TEST_UMASK);
      final Path dir = new Path("/test/newDir");
      assertTrue(fs.mkdirs(dir, new FsPermission((short)0777)));
      FileStatus status = fs.getFileStatus(dir);
      assertTrue(status.isDirectory());
      assertEquals((short)0715, status.getPermission().toShort());
    } finally {
      conf.set(CommonConfigurationKeys.FS_PERMISSIONS_UMASK_KEY, oldUmask);
    }
  }


I can see what's  happening here -UMASK is being set and the permissions
being masked off.

But: FileSystem.setPermissions() ignores UMASK -I can use it to set any
permissions I want.

So: why the different behaviour on the two permission-setting operations?
And why aren't there any tests for setPermissions() to formalise its
behaviour?

-steve

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message