apache/accumulo

Disallow eventual scans of accumulo metadata and root tables

Closed this issue · 4 comments

Is your feature request related to a problem? Please describe.
Scans using an eventual consistency level should never be allowed to run against the accumulo namespace.
This is to ensure that data results loaded from the metadata table and root tables are always accurate and not out of date.
Inaccurate results being returned could lead to system failure if used for administration actions.

Describe the solution you'd like
Scanners using a consistency level of eventual should fail immediately when attempting to scan the accumulo. namespace. Likewise the scan servers should also fail client scans to the accumulo. namespace.

Describe alternatives you've considered
Handling the scan failure in the client is faster, but if a malicious client modifies the client jar, then the scan server still needs to handle additional failures.

Additional context
Because this is at a namespace level, it should be easier to have a simple deny rule then needing to keep track of any additional accumulo.tables that are added in future versions.

Do we want to preclude users from being able to perform eventual scans on these tables? Just wondering if there is a use-case where this is needed and whether or not it could be enforced that eventual scans on the accumulo namespace are not allowed from within the server processes and utilities.

@keith-turner brought up that maybe we want to block this for all users except the system user.
We might have a valid use-case for certain utility functions in accumulo that produce reports or metrics for troubleshooting that would run as the system user.

This only applies to elasticity, but would we also want to disallow eventual scans on the new FATE table that is now part of the accumulo namespace?

This only applies to elasticity, but would we also want to disallow eventual scans on the new FATE table that is now part of the accumulo namespace?

I took care of this in elasticity