[ https://issues.apache.org/jira/browse/HDFS-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Wei-Chiu Chuang updated HDFS-10324: ----------------------------------- Attachment: HDFS-10324.005.patch Rev05: Thanks [~xyao] and [~andrew.wang]. I added an overloaded {{HdfsAdmin#createEncryptionZone}} API as well as a new {{HdfsAdmin#provisionEncryptionZoneTrash}} API. The crypto CLI now calls these two {{HdfsAdmin}} APIs instead of using {{DistributedFileSystem}} directly. > Trash directory in an encryption zone should be pre-created with sticky bit > --------------------------------------------------------------------------- > > Key: HDFS-10324 > URL: https://issues.apache.org/jira/browse/HDFS-10324 > Project: Hadoop HDFS > Issue Type: Bug > Components: encryption > Affects Versions: 2.8.0 > Environment: CDH5.7.0 > Reporter: Wei-Chiu Chuang > Assignee: Wei-Chiu Chuang > Attachments: HDFS-10324.001.patch, HDFS-10324.002.patch, > HDFS-10324.003.patch, HDFS-10324.004.patch, HDFS-10324.005.patch > > > We encountered a bug in HDFS-8831: > After HDFS-8831, a deleted file in an encryption zone is moved to a .Trash > subdirectory within the encryption zone. > However, if this .Trash subdirectory is not created beforehand, it will be > created and owned by the first user who deleted a file, with permission > drwx------. This creates a serious bug because any other non-privileged user > will not be able to delete any files within the encryption zone, because they > do not have the permission to move directories to the trash directory. > We should fix this bug, by pre-creating the .Trash directory with sticky bit. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org