Permissions and Inheritance

Within the RDMS, we support four levels of permissions or user privileges to files and folders. These permissions are either automatically assigned when a file or folder enters the RDMS, or they can be defined by the user(s).

In an order of ascending privileges, these permissions are 'Null', 'Read', 'Read/Write' and 'Own'.

Please see the following table for a summary of what these different permissions allow within the RDMS:

Permission Level	Read	Modify	Create New	Delete	Share
Null
Read
Write
Own

And for a more detailed explanation of what this permissions mean:

Own: The user owns the data object (file) or the collection (folder) and has the full permission on reading, modifying (including deletion), and sharing. This permission is assigned automatically to a file a user uploads into their RDMS Home Drive, for example.

Write: The user has read and write access to the object. This permission level does not allow you to rename or delete the object.

Read: The user can only read the object or its content. This also allows to make a (editable) copy of the file/folder.

Null: The user does not have any permission on the object. One can use 'none' when removing the previously assigned permissions to a user.

Important Note

• If you remove your own permissions, you will no longer be able to restore them even if you were the original owner of the object. This worked in previous versions of IRODS, but was removed in later updates.
• While 'write' permissions allow to create new objects and modify existing ones, it does not allow for the deletion of objects nor to rename them. The reason why renaming is blocked for the write permission is because iRODS handles renaming as creating a new object with the new name and deleting the old object. As such, renaming is a sort of deletion.

Permission inheritance means that the permissions set on a folder are also propagated to its subfolders and files. If permission inheritance is activated, newly created files and folders inherit the permission of the main folder.

By default, permission inheritance is active within the RDMS for RDMS Team Drives and RDMS Projects, but it can also be disabled by the user. To do so, you need to right-click the folder where you would like to turn permission inheritance off and select the highlighted menu item (see “future” screenshot).

If you decide to disable permission inheritance, you should be aware that this means that permissions on all (sub)folders and files have to be set individually.

Also, it should be noted that it is also possible to modify user permissions on specific subfolders or files when permission inheritance is activated on the main folder.

In order to make this concept clearer, we are going to describe a general use case and show what happens when permission inheritance are turned on or off. Please bear in mind that we will be considering a basic set up, but that for more complex cases the effect of permission inheritance might not be immediately straightforward.

General Use Case: User A uploads a file to folder in their Team Drive. The destination folder has three RDMS users with permissions: User A has Write permissions, User B has Own permissions, User C has Read permissions. User A is the one generating the data. User C acts as a reviewer of the data, instead. Finally, User B is the user responsible for the project.

User A uploads the file. User A has now Write permission on the file, so User A is now unable to change the permissions on the file. User A retains the ability to modify the file. In the Team Drive, both User B and User C can now see the uploaded file. User C is able to view the file, but not much else. User B has now ownership of the file, so they can change permissions on the file, if needed. User B can now also rename and delete the file, along with modifying it.

User A uploads the file. User A obtains Own permission on the file, since they uploaded it. In the Team Drive, both User B and User C cannot see the file. Effectively for them, nothing changed in the Team Drive. If user A wants to grant some permission to them, User A needs to do so manually. Such a setup would allow User A to directly grant User C Write permission after the file was uploaded. User B was granted Read permission, because they do not need to modify that specific file, for example.