CASSANDRA-18070 trunk: Add SELECT_MASKED permission #2146
Conversation
adelapena
force-pushed
the
18070-trunk
branch
3 times, most recently
from
377b30d to
6729d21
Compare
| Object[] maskedRow = row(0, 7, 7, 7); | ||
|
|
||
| // test queries with default permissions (no UNMASK nor SELECT_MASKED) | ||
| assertWithAuthSpin(() -> { |
There was a problem hiding this comment.
If my eyes aren't fooling me aren't we just repeating the same queries over and over again? Did you do this intentionally or would you consider some type of looping to avoid the repeats?
There was a problem hiding this comment.
I think that the queries tested of every block are different to each other. And the blocks are different to each other on whether they return a masked or unmasked row, or an authorization failure. The only blocks that are repeated are the ones for only UNMASK permission and for both UNMASK and SELECT_MASKED permissions, and the ones for defaults and manually removed permissions. I can put those pairs on blocks on separate methods to save some duplication, although I'm not sure that actually improves readability.
As for the differences test to test, they might look similar but they aren't identical, since different schemas allow different queries.
Allows to attach the native masking functions added by CASSANDRA-17941 to the definitions of table columns in the schema, as defined by CEP-20. The functions masking a column can be specified on CREATE TABLE queries, right at the end of the column definition. The mask of a column can also be changed or dropped with an ALTER TABLE query. Once a column is masked, SELECT queries will always return the masked value of the column. That masking is done on the coordinator, at the end of the query execution. Thus, masking won't affect any filters or ordering, which would be based on the clear values of the masked columns. Column masks are stored on the system table system_schema.column_masks. patch by Andrés de la Peña; reviewed by Benjamin Lerer and Berenguer Blasi for CASSANDRA-18068
The new permission allows to see the clear data of columns with an attached mask. Superusers have it by default, whereas regular users don't have it. patch by Andrés de la Peña; reviewed by Benjamin Lerer and Berenguer Blasi for CASSANDRA-18069
The new permission allows to run SELECT queries restricting the clear values of masked columns. Superusers have it by default, whereas regular users don't have it. patch by Andrés de la Peña; reviewed by Benjamin Lerer and Berenguer Blasi for CASSANDRA-18070
belliottsmith
force-pushed
the
trunk
branch
2 times, most recently
from
df3eb40 to
54e39a9
Compare
…to SAICodecUtils (apache#2146) ### What is the issue CNDB-15619 changed writeHeader(DataOutput) to writeHeader(IndexOutput) ### What does this PR fix and why was it fixed Adds backward-compatible writeHeader(DataOutput) method
3 participants
Add new SELECT_MASKED permission. It allows to run SELECT queries filtering the clear values of masked columns.
Superusers have it by default, whereas regular users don't have it by default.
Users without UNMASK nor SELECT_MASKED permission won't be authorised to use masked columns on the WHERE part of a SELECT query.