Getting File Permissions

[DenisaCG]

Current State

In the current version of the extension, all files of an S3 bucket open in the JupyterLab UI as the user having full control to read, edit and save the contents. This is not a safe practice as a user could have permissions to read the contents of a file and not edit them - in the current architecture, the user would be able to edit the contents and only when trying to save the file, an error would come up, and all progress on the file would be lost.

Desired State

To complete the drives experience, object and bucket permissions need to be taken into account. Ideally, when getting and displaying the contents of a file, we should already know the user permissions for it - this would enable us to use the JupyterLab read-only flag on the file in case editing is not permitted.

Getting File or Bucket Permissions from an S3 Bucket

The aws sdk has a function meant to get the ACL of a file GetObjectAclCommand and its output looks something like this:

{
        "Grants": [
            {
                "Grantee": {
                    "ID": "123456789123456789", // canonical user id
                    "Type": "CanonicalUser"
                },
                "Permission": "FULL_CONTROL" // "READ" or "WRITE"
            }
        ],
        "Owner": {
            "ID": "123456789123456789" // canonical user id
        }
 }

The problem comes when trying to match the canonical user id with the credentials provided by the user (access key, secret key and, if applicable the session token). The official docs recommend finding this id by listing the buckets of the user, but this operation is not possible in the browser, as documented in this issue.

Possible Solutions

Another possible solution of finding the canonical user id mentioned in the docs would be to list theACL of a bucket or object we have previous knowledge of the user having access to or being the owner of, which seems troublesome to implement in our case.

One of the solutions we found was sending a pre-flight OPTIONS HTTP request to see if the action of saving the file was permitted without actually completing the action, and although the request worked perfectly in the terminal with curl, in the extension it's throwing a CORS error regarding the Access-Control-Allow-Origin (even though the origin is being mentioned in the request and the same origin is already set in the CORS rules of the bucket).