[
https://issues.apache.org/jira/browse/HBASE-7917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587952#comment-13587952
]
Francis Liu commented on HBASE-7917:
------------------------------------
Small typo:
"which globally.." I think you meant "which is globally writable"?
Instead of saying "if you want to", I'd say that it is required when security
is enabled else bulk load won't work. The same goes for AccessController. Let's
keep the coprocessor setup when using security as it was envisioned.
+1 on adding AccessController, though don't forget that AccessController has to
be added as a master coprocessor as well.
> Documentation for secure bulk load
> ----------------------------------
>
> Key: HBASE-7917
> URL: https://issues.apache.org/jira/browse/HBASE-7917
> Project: HBase
> Issue Type: Improvement
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Fix For: 0.95.0
>
> Attachments: hbase-7917_v1.patch
>
>
> One of our tests for bulk loading on a secure cluster failed, because of it
> was
> not configured properly. We should document the setup.
> From SecureBulkLoadEndpoint:
> {code}
> 1. Create an hbase owned staging directory which is
> * world traversable (711): /hbase/staging
> * 2. A user writes out data to his secure output directory: /user/foo/data
> * 3. A call is made to hbase to create a secret staging directory
> * which globally rwx (777): /user/staging/averylongandrandomdirectoryname
> * 4. The user makes the data world readable and writable, then moves it
> * into the random staging directory, then calls bulkLoadHFiles()
> *
> * Like delegation tokens the strength of the security lies in the length
> * and randomness of the secret directory.
> {code}
> See HBASE-5498 for details on secure bulk load.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
