-
Notifications
You must be signed in to change notification settings - Fork 8.3k
ROW POLICY on Distributed table not works when assigned via ROLE #31080
Copy link
Copy link
Closed
Labels
comp-rbacAuthorization: roles, grants, quotas, row-level security, access checks.Authorization: roles, grants, quotas, row-level security, access checks.unexpected behaviourResult is unexpected, but not entirely wrong at the same time.Result is unexpected, but not entirely wrong at the same time.
Description
It looks like #8926 doesn't cover the case when the initial user & intercluster user have different roles.
DROP TABLE IF EXISTS test_row_policies_local;
DROP TABLE IF EXISTS test_row_policies;
CREATE TABLE test_row_policies_local engine=MergeTree ORDER BY tuple() as select * FROM numbers(100);
CREATE TABLE test_row_policies ENGINE=Distributed( 'test_cluster_two_shards_localhost', default, test_row_policies_local) AS test_row_policies_local;
DROP USER IF EXISTS 'usr_1';
CREATE USER IF NOT EXISTS 'usr_1' IDENTIFIED BY '123';
DROP ROLE IF EXISTS 'role_1';
CREATE ROLE IF NOT EXISTS 'role_1';
GRANT 'role_1' TO 'usr_1';
GRANT SELECT ON default.test_row_policies TO 'role_1';
GRANT SELECT ON default.test_row_policies_local TO 'role_1';
GRANT CREATE TEMPORARY TABLE, REMOTE ON *.* TO 'role_1';
DROP ROW POLICY IF EXISTS 'all_data' ON default.test_row_policies, default.test_row_policies_local;
DROP ROW POLICY IF EXISTS 'usr1_data' ON default.test_row_policies, default.test_row_policies_local;
CREATE ROW POLICY 'all_data' ON default.test_row_policies, default.test_row_policies_local USING 1 TO ALL EXCEPT 'role_1';
CREATE ROW POLICY 'usr1_data' ON default.test_row_policies, default.test_row_policies_local USING number % 10 = 0 TO 'role_1';
-- now login as usr_1:
-- clickhouse-client --user usr_1 --password 123
select * from test_row_policies_local settings prefer_localhost_replica=0;
-- ^^^ that return correct (filtered) result, as expected
-- BUT
select * from test_row_policies settings prefer_localhost_replica=0;
-- returns all rows.
-- same with remote
select * from remote('127.0.0.2:9000',currentDatabase(),test_row_policies);It looks like when 2 users are used together the roles are picked only from one of them, so when i assign the ROW POLICY directly to the user (not to the ROLE) it works as expected:
DROP TABLE IF EXISTS test_row_policies_local;
DROP TABLE IF EXISTS test_row_policies;
CREATE TABLE test_row_policies_local engine=MergeTree ORDER BY tuple() as select * FROM numbers(100);
CREATE TABLE test_row_policies ENGINE=Distributed( 'test_cluster_two_shards_localhost', default, test_row_policies_local) AS test_row_policies_local;
DROP USER IF EXISTS 'usr_1';
CREATE USER IF NOT EXISTS 'usr_1' IDENTIFIED BY '123';
GRANT SELECT ON default.test_row_policies TO 'usr_1';
GRANT SELECT ON default.test_row_policies_local TO 'usr_1';
DROP ROW POLICY IF EXISTS 'all_data' ON default.test_row_policies, default.test_row_policies_local;
DROP ROW POLICY IF EXISTS 'usr1_data' ON default.test_row_policies, default.test_row_policies_local;
CREATE ROW POLICY 'all_data' ON default.test_row_policies, default.test_row_policies_local USING 1 TO ALL EXCEPT 'usr_1';
CREATE ROW POLICY 'usr1_data' ON default.test_row_policies, default.test_row_policies_local USING number % 10 = 0 TO 'usr_1';P.S. Most probably that problem will not happen if cluster is configured with 'secret' #13156
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
comp-rbacAuthorization: roles, grants, quotas, row-level security, access checks.Authorization: roles, grants, quotas, row-level security, access checks.unexpected behaviourResult is unexpected, but not entirely wrong at the same time.Result is unexpected, but not entirely wrong at the same time.