Differences

This shows you the differences between two versions of the page.

--- rdms:data:permissions [2023/05/11 14:26] – Correct behaviour of 'write' vs 'own' jelte
+++ rdms:data:permissions [2025/12/17 11:12] (current) – Changed section headings jelte
@@ Line 1: / Line 1: @@
 ====== Permissions and Inheritance======
-Within the RDMS, there are four levels of **permissions** or user privileges to files and folders.
+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).
-**Own**: The user owns the data object (file) or the collection (folder) and has the full permission on reading, modifying (including deletion), and sharing.
+In an order of ascending privileges, these permissions are 'Null', 'Read', 'Read/Write' and 'Own'.
-**Write**: The user has read and write access to the object.
+Please see the following table for a summary of what these different permissions allow within the RDMS:
-**Read**: The user can only read the object or its content. This also allows to make a (editable) copy of the file/folder.
+^  Permission Level      ^  Read       ^  Modify          ^   Create New   ^   Delete   ^   Share   ^
+|  **Null**    |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?nolink&20|}}     |   {{:rdms:data:1280px-eo_circle_red_blank.svg.png?nolink&20|}}  |   {{:rdms:data:1280px-eo_circle_red_blank.svg.png?nolink&20|}}  |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?nolink&20|}}   |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?nolink&20|}}        |
+|  **Read**    |  {{:rdms:data:eo_circle_green_checkmark.svg.png?nolink&20|}}     |   {{:rdms:data:1280px-eo_circle_red_blank.svg.png?nolink&20|}}  |   {{:rdms:data:1280px-eo_circle_red_blank.svg.png?nolink&20|}}  |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?nolink&20|}}   |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?nolink&20|}}        |
+|  **Write**  |  {{:rdms:data:eo_circle_green_checkmark.svg.png?nolink&20|}}     |  {{:rdms:data:eo_circle_green_checkmark.svg.png?nolink&20|}}   |  {{:rdms:data:eo_circle_green_checkmark.svg.png?nolink&20|}}  |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?nolink&20|}}   |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?nolink&20|}}        |
+|  **Own**    |  {{:rdms:data:eo_circle_green_checkmark.svg.png?nolink&20|}}     |  {{:rdms:data:eo_circle_green_checkmark.svg.png?nolink&20|}}   |  {{:rdms:data:eo_circle_green_checkmark.svg.png?nolink&20|}}  |  {{:rdms:data:eo_circle_green_checkmark.svg.png?nolink&20|}}    |  {{:rdms:data:eo_circle_green_checkmark.svg.png?nolink&20|}}   |
-**None**: The user does not have any permission on the object. One can use 'none' when removing the previously assigned permissions to a user. When you are the owner of an object and accidentally set your own permissions to 'none', you will internally still remain the owner and you can recover your privileges by again assigning another permission level.
+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**
-  * While 'write' permissions allow to create new objects and modify existing ones, it does not allow for the deletion of objects
+  * 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 =====
+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:solution:team|RDMS Team Drives]] and [[rdms:solution:projects|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:
+{{ :rdms:data:set_inheritance_1.png?direct&600 |}}
+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 [[..:access:linux:icommands|iCommands]], but the behavior is the same if the user would upload the data via another way (e.g. [[..:access:windows:cyberduck|Cyberduck]] or [[..:access:windows:winscp|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.
+==== Example: Permission Inheritance - Enabled ====
+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.
+<code>
+# 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
+</code>
+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.
+**Important Note:** It should be mentioned that **permission inheritance only counts for newly created files/folder**. If you move a file/folder from another location to a folder with permission inheritance enabled, it will still keep its original permissions!
+To work around that, you can create a copy of the file/folder that you want to transfer and delete the original data after successful copy. The reason is that a copy is counted as a new file/folder and the inheritance then applies.
+<code>
+# The 'rdms-testers@rug.nl' user has an already existing folder in the home collection.
+  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 enabled inheritance.
+  imv folder_test /rug/home/Test_Team/folder_with_inheritance
+# Even with enabled inheritance, the permissions of the original folder are kept. Move: Not counted 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 the user, does not move, but copies the folder to the destination with enabled inheritance.
+$ icp -r folder_test /rug/home/Test_Team/folder_with_inheritance
+# Checking the permission now shows that the inherited permission of the parent folder are applied. Copy: Counted 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
+</code>
+==== Example: Permission Inheritance - Disabled ====
+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.
-===== Inheritance =====
+<code>
+# 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
-Inheritance means that the permissions set on a collection/folder are also propagated to its subfolders and files. Also, with activated inheritance, newly created files and folder inherit the permission of the main folder.
+# 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
-By default, permission inheritance is active within the RDMS, but it can also be disabled on a per folder/collection basis.
+# Permissions on the newly uploaded file show that it only has one permission: own for the uploading user
-Users who decide to disable permission inheritance should be aware that this means that permissions on all (sub)folders and files have to be set individually.
+$ 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
+</code>
-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.
+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]]