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.

Also note that the below examples use the CLI client iCommands, but the behavior is the same if the user would upload the data via another way (e.g. Cyberduck or WinSCP). We only use iCommands in this example as it allows to easily display the permission inheritance information and the permissions in the same view. For users that upload via clients like Cyberduck/WinSCP, they need to check/adjust the permissions either also via iCommands or via the RDMS web interface.

In the below example, assume that you are the uploading user rdms-testers@rug.nl. In the present case, you upload to a Team Drive folder where the Team Drive owner gave you 'write' permissions. Also the permission inheritance is enabled. In this scenario, we assume that you upload a new file test.txt from your local system to the RDMS folder with inheritance enabled.

# In this case, the folder has inheritance enabled.
# The 'rdms-testers@rug.nl' user has write (modify_object) permissions.
$ ils -A /rug/home/Test_Team/folder_with_inheritance         
/rug/home/Test_Team/folder_with_inheritance:
        ACL - teamdrive-owner@rug.nl#rug:own rdms-testers@rug.nl#rug:modify_object   g:Test_Team#rug:modify_object   
        Inheritance - Enabled

# The 'rdms-testers@rug.nl' user uploads a new file from the local system to the RDMS folder
$ iput test.txt /rug/home/Test_Team/folder_with_inheritance  

# Permissions on the newly uploaded file show that it inherited the permission from the parent collection automatically
$ ils -A /rug/home/Test_Team/folder_with_inheritance/test.txt
  /rug/home/Test_Team/folder_with_inheritance/test.txt
        ACL - teamdrive-owner@rug.nl#rug:own   rdms-testers@rug.nl#rug:modify_object   g:Test_Team#rug:modify_object  

As can be seen above, the newly uploaded file now has exactly the same permissions as where set on the parent folder, for example you have 'write' access while the owner of the team drive still has 'own' permissions. This is the effect of inheritance.