[
https://issues.apache.org/jira/browse/HAWQ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420590#comment-15420590
]
Lili Ma edited comment on HAWQ-256 at 8/15/16 3:43 AM:
-------------------------------------------------------
Below is the detailed list of default behaviors for the object operation if no
privilege is specified.
1. A database is allowed for connecting and creating temp table. Which means,
user A creates a database, everyone can connect to this database, and create
temp table into it.
2. Language is allowed for using. Which means, user A creates a language,
everyone can use this language.
3. Function is allowed for executing. Which means, user A defines a function,
then everyone can execute the function.
[~bosco], I think your suggestion on assigning a group "public" and assigns
each resource the default behavior for this group makes sense. For the 'deny'
operation, say, "I don't want user A to connect to database 1", we can simply
add a "deny" record in Ranger 0.6, say, adding userA to the blacklist for
database1. But for Ranger 0.5, what we can do for it?? For [~hubertzhang]'s
solution for removing the user A out of 'public' group, then we need to keep
one 'public' group for each object, I'm afraid there will be too many groups
there...
[~bosco], could you share the upgrade possibility for the user to upgrade
Ranger 0.5 to Ranger 0.6? Does the user need many efforts to do the upgrade? If
not, I think we can just simply consider supporting Ranger 0.6. Things will get
more clear then, Thanks:)
was (Author: lilima):
Below is the detailed list of default behaviors for the object operation if no
privilege is specified.
1. A database is allowed for connect and create temp table. Which means, user A
creates a database, everyone can connect to this database, and create temp
table into it.
2. Language is allowed to use. Which means, user A creates a language, everyone
can use this language.
3. Function is allowed to execute. Which means, user A defines a function, then
everyone can execute the function.
[~bosco], I think your suggestion on assigning a group "public" and assigns
each resource the default behavior for this group makes sense. For the 'deny'
operation, say, "I don't want user A to connect to database 1", we can simply
add a "deny" record in Ranger 0.6, say, adding userA to the blacklist for
database1. But for Ranger 0.5, what we can do for it?? For [~hubertzhang]'s
solution for removing the user A out of 'public' group, then we need to keep
one 'public' group for each object, I'm afraid there will be too many groups
there...
[~bosco], could you share the upgrade possibility for the user to upgrade
Ranger 0.5 to Ranger 0.6? Does the user need many efforts to do the upgrade? If
not, I think we can just simply consider supporting Ranger 0.6. Things will get
more clear then, Thanks:)
> Integrate Security with Apache Ranger
> -------------------------------------
>
> Key: HAWQ-256
> URL: https://issues.apache.org/jira/browse/HAWQ-256
> Project: Apache HAWQ
> Issue Type: New Feature
> Components: PXF, Security
> Reporter: Michael Andre Pearce (IG)
> Assignee: Lili Ma
> Fix For: backlog
>
> Attachments: HAWQRangerSupportDesign.pdf
>
>
> Integrate security with Apache Ranger for a unified Hadoop security solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
