Asset Permissions
Once you share an asset with users and organizations, you might wonder what access each user has to each asset. Users can be members of more than one organization, and users can share assets with multiple other users and organizations. With this in mind, it may be difficult to find out what permissions each user has on each asset. This document outlines the permission logic in TileDB, empowering you to develop strategies to share assets that fit your organization’s needs.
Permissions on individual assets
If a user belongs to more than one organization, and each organization has different permissions on an asset, that user will receive the union of the following permissions:
- The permissions of each organization to which the user belongs.
- The permissions given to the user themselves.
For example, consider a user who belongs to two organizations, and one organization has read access on an asset and another organization has write access on that same asset. In this case, the user will have both read and write permissions on that asset.
Permissions on group assets
VCF, SOMA, biomedical imaging, point cloud, geometries, raster, and vector search are all specialized group assets in TileDB. As mentioned in Share Assets, these objects require you to specify both regular permissions on the asset as well as content permissions, permissions on the assets contained within the parent asset.
If you are the owner of the parent asset as well as all child assets, and you share an asset with a user or an organization that already has permissions on one or more of the child assets, TileDB overwrites the permissions of that user or organization for those objects with what you select in the Content permissions drop down.
If a user belongs to more than one organization, and one organization already has permissions on a child asset, setting content permissions for a different organization to which that user belongs has no effect on the permissions given to the first organization.
Revoking access to a user or an organization on a parent asset also revokes access to all child assets, even if that user or organization had permissions to the child asset before the content permissions were set on the parent.
Examples
For these examples, you will use the following assets and namespaces to illustrate how permissions work:
- Users named User1, User2, and User3
- An organization named Org1, of which User1 and User2 are members
- An organization named Org2, of which User2 is a member
- A group named Group1, owned by User3
- Two arrays, Array1 and Array2, each owned by User3 and contained in Group1
Give Org1 write access to Array1
User3 gives Org1 write access to Array1. Because User1 and User2 are direct members of Org1, User1 and User2 now have write access to Array1.
Give Org2 read access to Array1
User3 now gives Org2 read access to Array1.
- User1’s permissions on Array1 are unchanged, because they’re not a member of Org2.
- Because Org2 now has read access to Array1, User2 now has both read and write access to Array1.
Give Org2 read-write access to Array2
User3 gives Org2 read-write access to Array2. Because Org2 has read-write access to Array2, User2 now has read-write access to Array2.
Give permissions on Group1 to Org1
User3 gives the following permissions to Org1 on Group1:
- Permissions: read-write
- Content permissions: read-only
This has the following effect:
- Org1’s permissions on Array1 change from write to read. Thus, User1 can no longer write to and can only read from Array1.
- Org1 now has read permissions on Array2. Thus, User1 can now read Array2
- Org2’s permissions on Array1 and Array2 remain unchanged. Thus, User2 still has read access on Array1 and read-write access on Array2.
- Org1 has read-write permissions on Group1. Thus, User1 and User2 have read-write permissions on Group1.
Remove permissions on Group1 from Org1
User3 now removes permissions on Group1 from Org1. This has the following effect:
- Org1 no longer has access to Group1, Array1, or Array2. Thus:
- User1 and User2 no longer have access to Group1.
- User1 no longer has access to Array1 or Array2.
- Org2’s permissions remain unchanged. Thus, User2 still has read access on Array1 and read-write access on Array2.