[
https://issues.apache.org/jira/browse/KUDU-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15866522#comment-15866522
]
Todd Lipcon commented on KUDU-1855:
-----------------------------------
I'm working on a patch that does the following:
- add a new --umask flag which can be set to the octal-formatted umask. The
default is 077 (so files would be only readable/writable by the kudu user
itself)
- when the fs manager starts up, it checks that the existing directories
conform to the configured umask and chmods them if not (eg 0755 -> 0700)
One question I'd like another opinion on: even with this setting, files created
using pb_util will end up with 0600 permissions (even if the user had set the
umask to 077) This means it's impossible to configure Kudu in such a way that
the kudu *group* can read the data on disk. Do you think that's OK, or should
we try to make the temporary files also conform to the configured umask?
The other places we create files either use a umask 0666 (log_index.cc) or 0664
(env_posix.cc). So, we should probably try to make them all consistent.
> Kudu file UNIX permissions are inconsistent
> -------------------------------------------
>
> Key: KUDU-1855
> URL: https://issues.apache.org/jira/browse/KUDU-1855
> Project: Kudu
> Issue Type: Bug
> Components: security
> Affects Versions: 1.3.0
> Reporter: Adar Dembo
> Priority: Blocker
>
> Right now the access modes of Kudu files on disk are quite inconsistent. For
> example:
> {noformat}
> 694296 0 drwxr-xr-x 4 kudu kudu 27 Jun 21 2016
> /data/1/kudu/tablet
> 2150110267 0 drwxr-xr-x 5 kudu kudu 71 Jan 17 17:42
> /data/1/kudu/tablet/data
> 2150124127 4 -rw------- 1 kudu kudu 665 Jun 21 2016
> /data/1/kudu/tablet/data/instance
> 702851 16 drwxr-xr-x 2 kudu kudu 12288 Jan 31 14:02
> /data/1/kudu/tablet/data/tablet-meta
> 702894 12 -rw------- 1 kudu kudu 9501 Jan 22 13:38
> /data/1/kudu/tablet/data/tablet-meta/33cc61001d1442048a588f930d973464
> ...
> 2153868729 8 -rw------- 1 kudu kudu 8109 Jan 12 22:26
> /data/1/kudu/tablet/data/consensus-meta/83a2f75a88bd48f5a8ec28f8328af481
> 702854 152 drwxr-xr-x 2 kudu kudu 110592 Jan 23 16:59
> /data/1/kudu/tablet/data/data
> 1545641 0 -rw-r--r-- 1 kudu kudu 10743091200 Jan 9 13:06
> /data/1/kudu/tablet/data/data/bdf6d87c2ba34d598327b0b9e159a5ea.data
> 705690 4 -rw------- 1 kudu kudu 990 Jun 21 2016
> /data/1/kudu/tablet/data/data/block_manager_instance
> 278147 652 -rw-r--r-- 1 kudu kudu 660084 Aug 15 00:09
> /data/1/kudu/tablet/data/data/3917e1185471419786f59ad72bb7ba63.metadata
> 290587 0 -rw-r--r-- 1 kudu kudu 10746855424 Jan 9 13:05
> /data/1/kudu/tablet/data/data/3917e1185471419786f59ad72bb7ba63.data
> 291129 672 -rw-r--r-- 1 kudu kudu 681669 Aug 15 00:09
> /data/1/kudu/tablet/data/data/756bd793f0c24188853e096f835ba7b4.metadata
> {noformat}
> I suspect it's due to the difference of "files opened as temp files and
> renamed into place" and "files opened directly". The former have permissions
> that are even more restrictive than the umask (022), while the latter adhere
> to the umask.
> I don't know whether more restrictive or less restrictive modes should be
> used, but I don't see any reason why all files in Kudu's filesystem layout
> shouldn't have the same permissions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
