1 # Copyright (C) The Arvados Authors. All rights reserved.
3 # SPDX-License-Identifier: AGPL-3.0
5 require '20200501150153_permission_table_constants'
10 def update_permissions perm_origin_uuid, starting_uuid, perm_level, edge_id=nil
12 # Update a subset of the permission table affected by adding or
13 # removing a particular permission relationship (ownership or a
16 # perm_origin_uuid: This is the object that 'gets' the permission.
17 # It is the owner_uuid or tail_uuid.
19 # starting_uuid: The object we are computing permission for (or head_uuid)
21 # perm_level: The level of permission that perm_origin_uuid gets for starting_uuid.
23 # perm_level is a number from 0-3
27 # or call with perm_level=0 to revoke permissions
29 # check: for testing/debugging, compare the result of the
30 # incremental update against a full table recompute. Throws an
31 # error if the contents are not identical (ie they produce different
36 # Give a change in a specific permission relationship, we recompute
37 # the set of permissions (for all users) that could possibly be
38 # affected by that relationship. For example, if a project is
39 # shared with another user, we recompute all permissions for all
40 # projects in the hierarchy. This returns a set of updated
41 # permissions, which we stash in a temporary table.
43 # Then, for each user_uuid/target_uuid in the updated permissions
44 # result set we insert/update a permission row in
45 # materialized_permissions, and delete any rows that exist in
46 # materialized_permissions that are not in the result set or have
49 # see db/migrate/20200501150153_permission_table.rb for details on
50 # how the permissions are computed.
53 # For changes of ownership, edge_id is starting_uuid. In turns
54 # out most invocations of update_permissions are for changes of
55 # ownership, so make this parameter optional to reduce
57 # For permission links, the uuid of the link object will be passed in for edge_id.
58 edge_id = starting_uuid
61 ActiveRecord::Base.transaction do
63 # "Conflicts with the ROW EXCLUSIVE, SHARE UPDATE EXCLUSIVE, SHARE
64 # ROW EXCLUSIVE, EXCLUSIVE, and ACCESS EXCLUSIVE lock modes. This
65 # mode protects a table against concurrent data changes."
66 ActiveRecord::Base.connection.execute "LOCK TABLE #{PERMISSION_VIEW} in SHARE MODE"
69 # BUG #15160: planner overestimates number of rows in join when there are more than 200 rows coming from CTE
70 # https://www.postgresql.org/message-id/152395805004.19366.3107109716821067806@wrigleys.postgresql.org
72 # For a crucial join in the compute_permission_subgraph() query, the
73 # planner mis-estimates the number of rows in a Common Table
74 # Expression (CTE, this is a subquery in a WITH clause) and as a
75 # result it chooses the wrong join order. The join starts with the
76 # permissions table because it mistakenly thinks
77 # count(materalized_permissions) < count(new computed permissions)
78 # when actually it is the other way around.
80 # Because of the incorrect join order, it choose the wrong join
81 # strategy (merge join, which works best when two tables are roughly
82 # the same size). As a workaround, we can tell it not to use that
83 # join strategy, this causes it to pick hash join instead, which
84 # turns out to be a bit better. However, because the join order is
85 # still wrong, we don't get the full benefit of the index.
87 # This is very unfortunate because it makes the query performance
88 # dependent on the size of the materalized_permissions table, when
89 # the goal of this design was to make permission updates scale-free
90 # and only depend on the number of permissions affected and not the
91 # total table size. In several hours of researching I wasn't able
92 # to find a way to force the correct join order, so I'm calling it
93 # here and I have to move on.
95 # This is apparently addressed in Postgres 12, but I developed &
96 # tested this on Postgres 9.6, so in the future we should reevaluate
97 # the performance & query plan on Postgres 12.
99 # https://git.furworks.de/opensourcemirror/postgresql/commit/a314c34079cf06d05265623dd7c056f8fa9d577f
101 # Disable merge join for just this query (also local for this transaction), then reenable it.
102 ActiveRecord::Base.connection.exec_query "SET LOCAL enable_mergejoin to false;"
104 temptable_perms = "temp_perms_#{rand(2**64).to_s(10)}"
105 ActiveRecord::Base.connection.exec_query %{
106 create temporary table #{temptable_perms} on commit drop
107 as select * from compute_permission_subgraph($1, $2, $3, $4)
109 'update_permissions.select',
110 [[nil, perm_origin_uuid],
111 [nil, starting_uuid],
115 ActiveRecord::Base.connection.exec_query "SET LOCAL enable_mergejoin to true;"
117 ActiveRecord::Base.connection.exec_delete %{
118 delete from #{PERMISSION_VIEW} where
119 target_uuid in (select target_uuid from #{temptable_perms}) and
120 not exists (select 1 from #{temptable_perms}
121 where target_uuid=#{PERMISSION_VIEW}.target_uuid and
122 user_uuid=#{PERMISSION_VIEW}.user_uuid and
125 "update_permissions.delete"
127 ActiveRecord::Base.connection.exec_query %{
128 insert into #{PERMISSION_VIEW} (user_uuid, target_uuid, perm_level, traverse_owned)
129 select user_uuid, target_uuid, val as perm_level, traverse_owned from #{temptable_perms} where val>0
130 on conflict (user_uuid, target_uuid) do update set perm_level=EXCLUDED.perm_level, traverse_owned=EXCLUDED.traverse_owned;
132 "update_permissions.insert"
135 check_permissions_against_full_refresh
141 def check_permissions_against_full_refresh
142 # No-op except when running tests
143 return unless Rails.env == 'test' and !Thread.current[:no_check_permissions_against_full_refresh]
145 # For checking correctness of the incremental permission updates.
146 # Check contents of the current 'materialized_permission' table
147 # against a from-scratch permission refresh.
149 q1 = ActiveRecord::Base.connection.exec_query %{
150 select user_uuid, target_uuid, perm_level, traverse_owned from #{PERMISSION_VIEW}
151 order by user_uuid, target_uuid
152 }, "check_permissions_against_full_refresh.permission_table"
154 q2 = ActiveRecord::Base.connection.exec_query %{
155 select pq.origin_uuid as user_uuid, target_uuid, pq.val as perm_level, pq.traverse_owned from (
156 #{PERM_QUERY_TEMPLATE % {:base_case => %{
157 select uuid, uuid, 3, true, true from users
159 :edge_perm => 'edges.val'
160 } }) as pq order by origin_uuid, target_uuid
161 }, "check_permissions_against_full_refresh.full_recompute"
163 if q1.count != q2.count
164 puts "Didn't match incremental+: #{q1.count} != full refresh-: #{q2.count}"
167 if q1.count > q2.count
168 q1.each_with_index do |r, i|
170 puts "+#{r}\n-#{q2[i]}"
175 q2.each_with_index do |r, i|
177 puts "+#{q1[i]}\n-#{r}"
184 def skip_check_permissions_against_full_refresh
185 check_perm_was = Thread.current[:no_check_permissions_against_full_refresh]
186 Thread.current[:no_check_permissions_against_full_refresh] = true
190 Thread.current[:no_check_permissions_against_full_refresh] = check_perm_was
194 # Used to account for permissions that a user gains by having
195 # can_manage on another user.
197 # note: in theory a user could have can_manage access to a user
198 # through multiple levels, that isn't handled here (would require a
199 # recursive query). I think that's okay because users getting
200 # transitive access through "can_manage" on a user is is rarely/never
201 # used feature and something we probably want to deprecate and remove.
202 USER_UUIDS_SUBQUERY_TEMPLATE = %{
203 select target_uuid from materialized_permissions where user_uuid in (%{user})
204 and target_uuid like '_____-tpzed-_______________' and traverse_owned=true and perm_level >= %{perm_level}