fix: DATASET_READ_TABLE read permissions

[SofiaSazonova]

Feature or Bugfix

• Bugfix

Detail

• backfill DATASET_READ_TABLE permissions
• delete this permissions, when dataset tables are revoked or deteled

Relates

• #1173

Security

Please answer the questions below briefly where applicable, or write N/A. Based on OWASP 10.

• Does this PR introduce or modify any input fields or queries - this includes fetching data from storage outside the application (e.g. a database, an S3 bucket)?
  • Is the input sanitized?
  • What precautions are you taking before deserializing the data you consume?
  • Is injection prevented by parametrizing queries?
  • Have you ensured no eval or similar functions are used?
• Does this PR introduce any functionality or component that requires authorization?
  • How have you ensured it respects the existing AuthN/AuthZ mechanisms?
  • Are you logging failed auth attempts?
• Are you using or adding any cryptographic features?
  • Do you use a standard proven implementations?
  • Are the used keys controlled by the customer? Where are they stored?
• Are you introducing any new policies/roles/users?
  • Have you used the least-privilege principle? How?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[SofiaSazonova]

DATASET_TABLE_READ = [GET_DATASET_TABLE, PREVIEW_DATASET_TABLE]

Checks

• [x] check DATASET_TABLE_READ against the table when we execute the get_table service function DatasetTableService, line 41
• [x] check PREVIEW_DATASET_TABLE against the table when we execute the preview service function DatasetTableService line 98

Give permissions

• [x] attach DATASET_TABLE_READ permission to the dataset owner and stewards when the table is created DatasetTableService line 146
• [x] attach DATASET_TABLE_READ permission to the new stewards when the table is transferred to new stewards DatasetService line 520
• [x] attach DATASET_TABLE_READ permissions to the share requester group when the table is shared ShareObjectService line 317

Remove permissions

• [x] remove all existing resource policies for the table permissions when the table is deleted DatasetTableService line 80
• [x] remove DATASET_TABLE_READ permissions to old stewards when the table is transferred to new stewards DatasetService line 512
• [x] remove DATASET_TABLE_READ permissions to the share requester group when the table is revoked ShareItemService line 107

Database chages

• [x] Migration script that creates the new permission type and creates records backfilling the existing datasets and shares corresponding permissions.

[SofiaSazonova]

Also solves #1171 steps 2 and 3

Step1. Grant permissions to env.admin --> DatasetService.grant_admin_permissions_on_dataset

[SofiaSazonova]

After conversation with @noah-paige I understood that for step 1 I have done the opposite thing. So, reverting it

[noah-paige]

Just 1 pending comment on migration script

Otherwise I think this PR is good and it solves issue #1171 but I am not sure it solves #1173 completely.

For that one I think it is more related to the following scenario:

• Share Approved
• Requestor Group gets DATASET_FOLDER_READ Permissions entry in DB for DatasetStorageLocation
• During processing - Share Failed --> Only option is to delete share
• Now if approver tries to approve again and all works this is fine (no dups) but at this moment the permission entry is orphaned - Requestor Group can still get folder even though Share_Failed

Similarly for revokes we remove the permissions then process the revoke - so a requestor loses permissions and then the revoke may fail

Maybe it is best that we add permissions post-approve processing of share and we remove permissions post-revoke processing of share

cc: @SofiaSazonova @dlpzx

[SofiaSazonova]

@noah-paige good catch! I will try to solve in the next commit

[SofiaSazonova]

@dlpzx @noah-paige I placed attachement/deletion of permissions inside share processor workers. So, the permissions are only granted|revoked when the share item is processed successfully.