DISCUSS: Don't modify the root user on table create

[ddanielr]

There is no need to add additional permissions to the root user since that user already has system privileges.

Confirms this works as expected with uno. Need to add tests.

[dlmarion]

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?

[ddanielr]

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.

[dlmarion]

@ddanielr - Thanks for the context, that helps. It sounds like the root cause of the issue then might be that the correct user is not logged in when running the create namespace and create table commands from the dump config files. I'm wondering if the dumpConfig commands could be updated to first switch to the user that owns the tables before creating the objects.

[keith-turner]

Would being able to run command as another user in the shell be help for this situation?

root> as user1 createtable table1
root> as user2 createtable table2

[ctubbsii]

The intended behavior is that the root user (or any user granted "SYSTEM" permission does not automatically get additional privileges to read/write/alter user tables). This follows the principle of least privilege, where the root user (or a delegated user with "SYSTEM" permission) has permissions to administer the system, but does not automatically have permission to do things to user data. As a privileged user, the root user (or delegate) can grant themselves permissions, but that is intentionally a second step. This limits the harm a privileged user can do unintentionally to user data.

This follows conventions in traditional RDBMS systems where the root/system user does not automatically have read/write/alter table permissions for a user's table in a database.