ddanielr commented on PR #5699: URL: https://github.com/apache/accumulo/pull/5699#issuecomment-3032418061
> I thought that a user could make it such that root does not have permissions on objects. For example: > > 1. Root user creates user1 > 2. Root user gives user1 permission to create namespace > 3. user1 creates a namespace and some tables in it > > I don't think at this point root can scan the tables in that namespace or do anything with them unless user1 gives root those permissions. Am I mis-remembering? You're not mis-remembering but it's not even based on the separate namespace. The root user has no ability to scan user-created tables even if the root user has `SystemPermission.SYSTEM` permissions in that table's namespace. I added a test in 119d21f to prove that the root user cannot scan a user created table in the default namespace. Then I modified the security objects to allow users with SYSTEM level permissions to perform table actions in 505f0a2. This caused the test I added to fail since the root user is now able to scan the user-created table so I then updated the test to pass in e81b3f5. This draft PR was created to try and answer why a root user's permission objects change when a root client session is taking the output of a previous `./accumulo admin dumpConfig -a` command and attempting to recreate a system configuration even when the `root_user.cfg` contents did not contain those previous table permissions. Currently, if the root user is creating tables, then it is automatically granted read permissions on those tables. A user would then need to go back through and modify the root user to remove those granted permissions. This seems like a tedious amount of work and made me question what is the purpose of `SystemPermission.SYSTEM` if granular permissions on each table are still needed. I looked at the documentation but didn't see anything that called out the specific permissions and their desired goals. Some (READ_TABLE, WRITE_TABLE) permissions are self-explanatory but SYSTEM seems to be ambiguous. **I don't think these changes should be merged in**, but rather used to discuss if this permissions model is expected. I.e. if SYSTEM is granted, then why isn't `NAMESPACE_READ` also granted. (I''ll update the title to make that clear). This is in support of adding an easier ability to restore the configuration from the current output of `dumpConfig` to help remove hurdles with the upgrade process to 4.0. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@accumulo.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
