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:

If you decide to disable permission inheritance, you will have to manually set the permissions on all (sub)folders and files contained in the folder where permission inheritance is turned off.

Please note that you can modify user permissions on specific subfolders or files even when permission inheritance is activated on the main folder. Having permission inheritance activated is meant to help you by automatically setting the permissions of new files and folders. It does not prevent you from changing them afterwards, should you need different permissions on specific files or folders.

Important Note: The RDMS considers a file or folder new if you upload it to the RDMS or if you copy it from an existing RDMS location. A file or folder is not considered new if you move it from an existing RDMS location. In this second case, you will need to manually modify the permissions on the file or folder. We recommend you verify the permissions assigned to a file or folder after you moved it to a new location, regardless of whether permission inheritance is enabled or disabled.

To display things more easily, we decided to use the CLI client iCommands in the screenshots below. Please note that the behavior of the RDMS regarding permission inheritance is the same if the user uploads their data another way (e.g. Cyberduck or WinSCP). If you use Cyberduck or WinSCP to upload data to the RDMS, you can check or adjust permission inheritance either via iCommands or via the RDMS web interface.

# The 'rdms-testers@rug.nl' user has an already existing folder in the home collection. 
# Please look to the 'ACL' entry to see which permission 'rdms-testers' has in this folder.
# In this case, the permission level is 'own'.
$  ils -A folder_test
/rug/home/rdms-testers@rug.nl/folder_test:
        ACL - rdms-testers@rug.nl#rug:own   
        Inheritance - Disabled

# The folder is now moved to a RDMS destination with permission inheritance enabled.
# The 'ACL' entry for this folder is:
#       ACL - teamdrive-owner@rug.nl#rug:own   rdms-testers@rug.nl#rug:modify_object   g:Test_Team#rug:modify_object
# So other users have permissions in this folder and 'rdms-testers' does not have 'own', but write permission (modify_object).
$  imv folder_test /rug/home/Test_Team/folder_with_inheritance

# We list the details of the folder again. See the 'ACL' entry to verify the permission level of 'rdms-testers'.
# Even with enabled inheritance, the permissions of the original folder are kept. 
# Move: Does not count as new data --> Inheritance is not applied.
$ ils -A /rug/home/Test_Team/folder_with_inheritance/folder_test
/rug/home/Test_Team/folder_with_inheritance/folder_test:
        ACL - rdms-testers@rug.nl#rug:own   
        Inheritance - Disabled

# Now we will show what happens if we copy the folder to the destination with enabled inheritance. 
$ icp -r folder_test /rug/home/Test_Team/folder_with_inheritance

# We list the details of the folder a third time. See the 'ACL' entry to verify the permission level of 'rdms-testers'.
# Checking the permission now shows that the inherited permission of the parent folder are applied. 
# Copy: Counts as new data --> Inheritance is applied. 
$ ils -A /rug/home/Test_Team/folder_with_inheritance/folder_test
/rug/home/Test_Team/folder_with_inheritance/folder_test:
        ACL - teamdrive-owner@rug.nl#rug:own   rdms-testers@rug.nl#rug:modify_object   g:Test_Team#rug:modify_object   
        Inheritance - Enabled

In order to make this concept clearer, we are going to describe two examples and show what happens when permission inheritance are either turned on or off. We also point out when enabling or disabling permission inheritance can be advantageous. 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.

In this example, we show what happens when the user rdms-testers@rug.nl (henceforth User) uploads new data to a Team Drive. The User has 'write' permissions in the Drive and permission inheritance is enabled. The User is uploading the new file test.txt from their 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.

Note: A good reason to have permission inheritance enabled in a Team Drive is to make sure that all new data is provided with the correct permissions, no matter who does the upload.

In this example, we now assume the same scenario: You are rdms-testers@rug.nl and you upload a new file test.txt to a RDMS Team Drive folder. The permissions on the Team Drive folder are exactly the same as in the scenario mentioned above with the exception that permission inheritance is disabled for the destination folder.

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

# 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_without_inheritance  

# Permissions on the newly uploaded file show that it only has one permission: own for the uploading user
$ ils -A /rug/home/Test_Team/folder_without_inheritance/test.txt
  /rug/home/Test_Team/folder_without_inheritance/test.txt
        ACL - rdms-testers@rug.nl#rug:own   

As you can see, the uploaded file now has only a single permission: Ownership for the creator (uploader), so 'own' for rdms-testers@rug.nl. There are no permissions for the team drive owner in this case. The file will be not accessible or even visible for this user.

In these case, you will need to set the permission by hand to the desired value. This can be done by yourself or also by the owner of the parent folder. If this is not working out, please contact rdms-support@rug.nl

Note: A good reason to have permission inheritance disabled in the top-level of a Team Drive is to allow for easy permission management when the permissions are not the same in all Team Drive locations. For instance, if User 1 should only have permissions in Folder 1 and User 2 should only have permissions in Folder 2, with permission inheritance disabled, you can then simply add the Users without having to remove other Users first when creating new folders. Permission inheritance can then be enabled again inside Folder 1 and Folder 2, to help keep track of the right permissions.