You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by "John Vines (JIRA)" <ji...@apache.org> on 2012/07/06 22:13:35 UTC
[jira] [Created] (ACCUMULO-677) Remove (deprecate) createUser call
with authorizations argument
John Vines created ACCUMULO-677:
-----------------------------------
Summary: Remove (deprecate) createUser call with authorizations argument
Key: ACCUMULO-677
URL: https://issues.apache.org/jira/browse/ACCUMULO-677
Project: Accumulo
Issue Type: Bug
Components: client
Affects Versions: 1.4.1, 1.4.2
Reporter: John Vines
Assignee: John Vines
Fix For: 1.5.0
Creating a user depends on a different ACL than granting Authorizations. If the user can do one, but not the other it will still create the user but float back an error. This can be confusing to end users, so I think we should isolate createUser to just creating the user. They can then be granted authorizations as need be.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ACCUMULO-677) Remove (deprecate) createUser
call with authorizations argument
Posted by "Christopher Tubbs (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACCUMULO-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426770#comment-13426770 ]
Christopher Tubbs commented on ACCUMULO-677:
--------------------------------------------
I suppose a system administrator could create the user account, while the data owner can grant an authorization (a concept I strongly like). After some consideration, I think I'm also in reluctant agreement with the above (I really liked the simplicity of "CREATE/ALTER USER").
Under this user management model, API changes should include add/remove methods for auths, rather than simply setAuths. Also, the API should be robust enough to assign and manage data owners, on a per-authorization basis to make this change useful. The ability to grant an authorization should be based on that user's relationship to the authorization in question (eg. data owner), not based on a blanket permission to grant all authorizations.
My concerns under this model, though, remain:
1) if the data owner only grants authorizations to existing users rather than creating users themselves, then a trust relationship must exist between the data owner and the system administrator who created the user, so that the data owner can trust that the user to whom they are assigning auths (based on user name) is the correct user,
2) this trust relationship may add security assumptions to the API that users need to be aware of (imagine a user admin deleting an existing user with authorizations, and re-creating it with a new password that he/she knows), and
3) the separation of responsibilities for user management may add confusion to end users of the type that this ticket intends to avoid.
> Remove (deprecate) createUser call with authorizations argument
> ---------------------------------------------------------------
>
> Key: ACCUMULO-677
> URL: https://issues.apache.org/jira/browse/ACCUMULO-677
> Project: Accumulo
> Issue Type: Improvement
> Components: client
> Affects Versions: 1.4.1, 1.4.2
> Reporter: John Vines
> Assignee: John Vines
> Priority: Minor
> Labels: acl, alter, api, create, permissions, security, user
> Fix For: 1.5.0
>
>
> Creating a user depends on a different ACL than granting Authorizations. If the user can do one, but not the other it will still create the user but float back an error. This can be confusing to end users, so I think we should isolate createUser to just creating the user. They can then be granted authorizations as need be.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ACCUMULO-677) Remove (deprecate) createUser call
with authorizations argument
Posted by "Christopher Tubbs (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACCUMULO-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christopher Tubbs updated ACCUMULO-677:
---------------------------------------
Priority: Minor (was: Major)
> Remove (deprecate) createUser call with authorizations argument
> ---------------------------------------------------------------
>
> Key: ACCUMULO-677
> URL: https://issues.apache.org/jira/browse/ACCUMULO-677
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Affects Versions: 1.4.1, 1.4.2
> Reporter: John Vines
> Assignee: John Vines
> Priority: Minor
> Fix For: 1.5.0
>
>
> Creating a user depends on a different ACL than granting Authorizations. If the user can do one, but not the other it will still create the user but float back an error. This can be confusing to end users, so I think we should isolate createUser to just creating the user. They can then be granted authorizations as need be.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ACCUMULO-677) Remove (deprecate) createUser
call with authorizations argument
Posted by "John Vines (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACCUMULO-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426877#comment-13426877 ]
John Vines commented on ACCUMULO-677:
-------------------------------------
I agree, we need add/remove instead of set.
As for data owners, I agree with you, but I don't think there's a clean way to do it. I could see a combination of a System.GRANT_AUTH and any authorizations the user possesses. That would provide a decent balance of ownership without making it too complex for people in less rigorous circumstances.
1 - Reasonable concern, but that could very well happen now in the case of changing auths for a user you did not create
2 - This is up to the Authorizor implementation, which should on create/delete (or both) ensure that users list of authorizations is empty
3- Yes, which is why I want to try to find a middle ground that provides the limitation of Authorizations while not making them unusable to those who aren't in dire need of them.
> Remove (deprecate) createUser call with authorizations argument
> ---------------------------------------------------------------
>
> Key: ACCUMULO-677
> URL: https://issues.apache.org/jira/browse/ACCUMULO-677
> Project: Accumulo
> Issue Type: Improvement
> Components: client
> Affects Versions: 1.4.1, 1.4.2
> Reporter: John Vines
> Assignee: John Vines
> Priority: Minor
> Labels: acl, alter, api, create, permissions, security, user
> Fix For: 1.5.0
>
>
> Creating a user depends on a different ACL than granting Authorizations. If the user can do one, but not the other it will still create the user but float back an error. This can be confusing to end users, so I think we should isolate createUser to just creating the user. They can then be granted authorizations as need be.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ACCUMULO-677) Remove (deprecate) createUser call
with authorizations argument
Posted by "Christopher Tubbs (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACCUMULO-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christopher Tubbs updated ACCUMULO-677:
---------------------------------------
Issue Type: Improvement (was: Bug)
> Remove (deprecate) createUser call with authorizations argument
> ---------------------------------------------------------------
>
> Key: ACCUMULO-677
> URL: https://issues.apache.org/jira/browse/ACCUMULO-677
> Project: Accumulo
> Issue Type: Improvement
> Components: client
> Affects Versions: 1.4.1, 1.4.2
> Reporter: John Vines
> Assignee: John Vines
> Priority: Minor
> Fix For: 1.5.0
>
>
> Creating a user depends on a different ACL than granting Authorizations. If the user can do one, but not the other it will still create the user but float back an error. This can be confusing to end users, so I think we should isolate createUser to just creating the user. They can then be granted authorizations as need be.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ACCUMULO-677) Remove (deprecate) createUser
call with authorizations argument
Posted by "Christopher Tubbs (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACCUMULO-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13424913#comment-13424913 ]
Christopher Tubbs commented on ACCUMULO-677:
--------------------------------------------
Why should they depend on a different ACL? Grant/Revoke was intended to be an "ALTER USER" ACL, whereas Create User was intended to be a "CREATE USER" ACL, and this would *include* creating the initial authorizations. When you view separate it as "CREATE" and "ALTER" on the object "USER", it makes complete sense in an object oriented way. Separating them makes less sense, because it treats "CREATE USER" and "ALTER USER" as two completely independent actions, completely ignoring the common object you are manipulating ("USER").
If you implemented the above, then to create a fully functioning user, you'd have to have two separate permissions. I understand the desire to change the API to match this paradigm, if you were to desire to switch to it, but I personally think that leaving the "CREATE USER" and "ALTER USER" paradigm in place is better. That said... without deprecating or changing the "CREATE"/"ALTER" paradigm, you could add to the API a method to create a user without authorizations (unless that already exists).
> Remove (deprecate) createUser call with authorizations argument
> ---------------------------------------------------------------
>
> Key: ACCUMULO-677
> URL: https://issues.apache.org/jira/browse/ACCUMULO-677
> Project: Accumulo
> Issue Type: Bug
> Components: client
> Affects Versions: 1.4.1, 1.4.2
> Reporter: John Vines
> Assignee: John Vines
> Fix For: 1.5.0
>
>
> Creating a user depends on a different ACL than granting Authorizations. If the user can do one, but not the other it will still create the user but float back an error. This can be confusing to end users, so I think we should isolate createUser to just creating the user. They can then be granted authorizations as need be.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ACCUMULO-677) Remove (deprecate) createUser
call with authorizations argument
Posted by "Christopher Tubbs (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACCUMULO-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426322#comment-13426322 ]
Christopher Tubbs commented on ACCUMULO-677:
--------------------------------------------
I'm all in favor of adding a more robust administrative set of permissions, to delegate the role of user management away from the root user. However, I think separating these out in the way you've suggested implies you're treating "authorization" as an independent object, disconnected from the user (but perhaps with a user property that gives it some meaning). I don't think that's the right approach in a user-centric model. It should be create/alter/delete/manage user... not create/alter/delete/manage authorization (with user attribute). Users and authorizations really aren't a separable concept, and I think it complicates things when you move away from authorizations as separate objects. (NOTE: I'm just talking about API here, not underlying implementation... I think the API should reflect a user-centric management model).
> Remove (deprecate) createUser call with authorizations argument
> ---------------------------------------------------------------
>
> Key: ACCUMULO-677
> URL: https://issues.apache.org/jira/browse/ACCUMULO-677
> Project: Accumulo
> Issue Type: Improvement
> Components: client
> Affects Versions: 1.4.1, 1.4.2
> Reporter: John Vines
> Assignee: John Vines
> Priority: Minor
> Labels: acl, alter, api, create, permissions, security, user
> Fix For: 1.5.0
>
>
> Creating a user depends on a different ACL than granting Authorizations. If the user can do one, but not the other it will still create the user but float back an error. This can be confusing to end users, so I think we should isolate createUser to just creating the user. They can then be granted authorizations as need be.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ACCUMULO-677) Remove (deprecate) createUser
call with authorizations argument
Posted by "John Vines (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACCUMULO-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426311#comment-13426311 ]
John Vines commented on ACCUMULO-677:
-------------------------------------
Authorizations can be extremely sensitive, moreso than read access to any table I would say. So you want the ability to keep the ability to alter them as segregated as possible, so you can have administrative users who can still function without having the ability to mess with users authorizations. The idea here is to have a administer who can go around creating accounts, resetting passwords, etc. but doesn't have the permissions to mess with users authorizations. That is, they don't have the permissions to grant access to data because their role is not granting data access.
Personally, I think that there may be a case for a dedicated permission for doling out permissions, perhaps restricted to only authorizations that user has (exception for root user), in order to restrict users from messing around in data spaces they otherwise shouldn't be messing with.
> Remove (deprecate) createUser call with authorizations argument
> ---------------------------------------------------------------
>
> Key: ACCUMULO-677
> URL: https://issues.apache.org/jira/browse/ACCUMULO-677
> Project: Accumulo
> Issue Type: Improvement
> Components: client
> Affects Versions: 1.4.1, 1.4.2
> Reporter: John Vines
> Assignee: John Vines
> Priority: Minor
> Labels: acl, alter, api, create, permissions, security, user
> Fix For: 1.5.0
>
>
> Creating a user depends on a different ACL than granting Authorizations. If the user can do one, but not the other it will still create the user but float back an error. This can be confusing to end users, so I think we should isolate createUser to just creating the user. They can then be granted authorizations as need be.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ACCUMULO-677) Remove (deprecate) createUser
call with authorizations argument
Posted by "David Medinets (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACCUMULO-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426559#comment-13426559 ]
David Medinets commented on ACCUMULO-677:
-----------------------------------------
I agree John when he said "The idea here is to have a administer who can go around creating accounts, resetting passwords, etc. but doesn't have the permissions to mess with users authorizations."
There are definitely situations were technical support people should not (must not!) see the data and, therefore, should not mess with authorizations. As one example, consider the health industry.
> Remove (deprecate) createUser call with authorizations argument
> ---------------------------------------------------------------
>
> Key: ACCUMULO-677
> URL: https://issues.apache.org/jira/browse/ACCUMULO-677
> Project: Accumulo
> Issue Type: Improvement
> Components: client
> Affects Versions: 1.4.1, 1.4.2
> Reporter: John Vines
> Assignee: John Vines
> Priority: Minor
> Labels: acl, alter, api, create, permissions, security, user
> Fix For: 1.5.0
>
>
> Creating a user depends on a different ACL than granting Authorizations. If the user can do one, but not the other it will still create the user but float back an error. This can be confusing to end users, so I think we should isolate createUser to just creating the user. They can then be granted authorizations as need be.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira