[
https://issues.apache.org/jira/browse/KUDU-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15865066#comment-15865066
]
Adar Dembo commented on KUDU-1855:
----------------------------------
My two cents:
bq. 1) should we explicitly set our own umask on process startup to something
restrictive like 077?
I don't know. I would assume that the system administrator has configured umask
(explicitly or implicitly) to some specific value, and we should honor whatever
it is.
That said, we should probably encourage vendors to default to restrictive
umasks like 077 in their Kudu service scripts and configuration tools.
bq. 2) should we add code to chmod 700 our data/wal dirs on startup, so that
people running previous versions would get their permissions fixed on upgrade?
Maybe not explicitly 700, but we could examine the umask, calculate the
appropriate chmod, and fix up any file/directory permissions that do not
comply. That could be expensive with the file block manager though.
bq. 3) does any of this need to be configurable? are there valid use cases
where people want g+rx or a+rx permissions? (eg maybe so admins in the 'kudu'
group could run offline tools?)
Yes, but see above; I think the umask _is_ that configuration mechanism. Might
be interesting to take a look at how other database projects manage on-disk
file permissions.
> 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)
