services/api/lib/update_permissions.rb

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