[
https://issues.apache.org/jira/browse/HIVE-18739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16414852#comment-16414852
]
Sergey Shelukhin edited comment on HIVE-18739 at 3/27/18 1:11 AM:
------------------------------------------------------------------
This situation is different, because appropriate security config is not obvious
or explicit.
For export, if the table is ACID, to work securely, the user must set up very
specific permissions on a separate database, that are not intuitive even in
isolation and may in fact be impossible (e.g. w/doAs and HDFS auth).
If the user sets up logical permissions, he will get logical results in your
example... if the user wants to give full access he can set up permissions to
give full access. If the user sets up logical permissions for export, he'll get
a security issue... generally it's not ideal to have smth unsecure by default.
So, I think we should do as much as easily possible to check... check that doAs
is off (because in that case I think it's not going to be secure), and maybe
check SQL policies if that's not too cumbersome or that ranger is enabled
(pretty sure it's impossible to check ranger policies, other than by actually
trying as a different user).
I think the best approach would be to add some sort of extra privilege and
protect the transient table with it instead.
cc [~thejas] as a HS2 security expert.
The synopsis is that ACID export works by doing create table as select in a
separate database that has to be accessible to all users (who do export), which
means during export a user with access to any database (and export) can see
data exported from any other database, regardless of permissions, unless that
separate database is set up in such manner that each user can only read his own
tables and not others'.
I'm -0 but feel free to advise here :)
was (Author: sershe):
This situation is different, because appropriate security config is not obvious
or explicit.
For export, if the table is ACID, to work securely, the user must set up very
specific permissions on a separate database, that are not intuitive even in
isolation and may in fact be impossible (e.g. w/doAs and HDFS auth).
If the user sets up logical permissions, he will get logical results in your
example... if the user wants to give full access he can set up permissions to
give full access. If the user sets up logical permissions for export, he'll get
a security issue... generally it's not ideal to have smth unsecure by default.
So, I think we should do as much as easily possible to check... check that doAs
is off (because in that case I think it's not going to be secure), and maybe
check SQL policies if that's not too cumbersome or that ranger is enabled
(pretty sure it's impossible to check ranger policies, other than by actually
trying as a different user).
I think the best approach would be to add some sort of extra privilege and
protect the transient table with it instead.
cc [~thejas] as a HS2 security expert.
The synopsis is that ACID export works by doing create table as select in a
separate database that has to be accessible to all users (who do export), which
means during a user with access to any database (and export) can see data
exported from any other database, regardless of permissions, unless that
separate database is set up in such manner that each user can only read his own
tables and not others'.
I'm -0 but feel free to advise here :)
> Add support for Export from Acid table
> --------------------------------------
>
> Key: HIVE-18739
> URL: https://issues.apache.org/jira/browse/HIVE-18739
> Project: Hive
> Issue Type: Sub-task
> Components: Transactions
> Reporter: Eugene Koifman
> Assignee: Eugene Koifman
> Priority: Major
> Attachments: HIVE-18739.01.patch, HIVE-18739.04.patch,
> HIVE-18739.04.patch, HIVE-18739.06.patch, HIVE-18739.08.patch,
> HIVE-18739.09.patch, HIVE-18739.10.patch, HIVE-18739.11.patch,
> HIVE-18739.12.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
