Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rdms:data:permissions [2026/01/14 14:21] – [Example: Permission Inheritance - Disabled] rephrasing giuliordms:data:permissions [2026/03/11 10:10] (current) – [Permissions and Inheritance] IRODS --> iRODS jelte
Line 1: Line 1:
 +{{indexmenu_n>3}}
 ====== Permissions and Inheritance====== ====== Permissions and Inheritance======
  
-Within the RDMSwe 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).+With the current version of iRODS, **ten levels** of permissions on data and metadata are available to the user. 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_Metadata', 'Read_Object', 'Create_Metadata', 'Modify_Metadata', 'Delete_Metadata', 'Create_Object', 'Modify_Object', 'Delete_Object', and 'Own'. You can set these permissions either by using the ''ichmod'' command in the Command Line Interface (CLI), or by using the web interface
  
-In an order of ascending privileges, these permissions are 'Null', 'Read', 'Read/Write' and 'Own'.+**Note**: The web interface lets you currently set **four levels** of permissions, as those were the ones available before the iRODS version update. In an order of ascending privileges, these permissions are 'Null', 'Read', 'Read/Write'and 'Own'. At the moment, the new permissions are displayed in the web interface, but can only be set using iCommands
  
-Please see the following table for a summary of what these different permissions allow within the RDMS:+Please see the following table for a summary of what these different permissions allow within the RDMS (corresponding permissions from the old four-level model noted in parantheses) :
  
- Permission Level       Read        Modify            Create New     Delete     Share   +^ Metadata ^ ^ ^ ^ Data ^ ^ ^ ^ ^ 
- **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|}}        +Permission Level ^ Read ^ Create ^ Modify ^ Delete ^ Read ^ Create ^ Modify ^ Delete ^ Share ^ 
- **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|}}        +| **Null** (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|}} | {{: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|}}        +| **Read_Object** (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: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|}} | 
- **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|}}   |+**Create_Metadata** | {{: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|}} | {{: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|}} | 
 +| **Modify_Metadata** | {{: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: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|}} | 
 +| **Delete_Metadata** | {{: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|}} | {{: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|}} | 
 +| **Modify_Object** (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: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:1280px-eo_circle_red_blank.svg.png?nolink&20|}} | {{:rdms:data:1280px-eo_circle_red_blank.svg.png?nolink&20|}} | 
 +| **Delete_Object** | {{: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|}} | {{: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|}} | 
 +| **Own** (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|}} | {{: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|}} |
  
 +**Note**: The table does not contain **Read_Metadata** and **Create_Object**, as these permissions are currently causing unexpected behaviour in the system. We advise not to use them.
  
-And for more detailed explanation of what this permissions mean+Finally, find below brief explanation of what the permissions mean and how they are linked to the old set of permissions.
  
-**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+  * **Null**: The user has no permissions on the object or metadata. The object is invisible to the user. You can use this permission to remove previously granted permissions on data and metadata.  
- +  * **Read_Object**: The user can display the data object and the metadata attached to it. The user can also download the data object from the RDMS. This level of permission corresponds to the **old READ** permission. 
-**Write**: The user has read and write access to the object. This permission level does not allow you to rename or delete the object. +  * **Create_Metadata**: The user has the same permissions as the permission level abovebut can also create new metadata entries for the data object. Existing metadata cannot be modified
- +  * **Modify_Metadata**: The user has the same permissions as the permission level above, but can now modify existing metadata entries. The user may not delete any metadata entry attached to the data object. 
-**Read**: The user can only read the object or its content. This also allows to make (editable) copy of the file/folder.  +  * **Delete_Metadata**: The user has the same permissions as the permission level above, but can now delete metadata entries. 
- +  * **Modify_Object**: The user has the same permissions as the permission level above, but can now modify the data object itself. This level of permission corresponds to the **old READ/WRITE** permission. With this level of permission, you can upload new version of the data and modify it, but you cannot delete it or rename it
-**Null**: The user does not have any permission on the objectOne can use 'none' when removing the previously assigned permissions to a user. +  * **Delete_Object**: The user has the same permissions as the permission level above, but can now delete and rename objects. As the sharing of data or setting permissions requires ownership of the data, these are actions not available to the user. 
 +  * **Own**: The user owns the data object (file) or the collection (folder) and has 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.
  
 **Important Note** **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. +  * 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.+  * While 'write' permissions allow the creation of new objects and the modification of existing ones, it does **not allow** for the deletion of objects nor the renaming of them. The reason why renaming is blocked for the write permission is that 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 =====
Line 43: Line 51:
 **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. **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 [[..:access:linux:icommands|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. [[..:access:windows:cyberduck|Cyberduck]] or [[..:access:windows:winscp|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. +To display things more easily, we decided to use the CLI client [[..:access:linux:icommands|iCommands]] in the examples 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. [[..:access:windows:cyberduck|Cyberduck]] or [[..:access:windows:winscp|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. 
  
 <code> <code>
-The 'rdms-testers@rug.nl' user has an already existing folder in the home collection.  +This is the folder with enabled inheritance that we use as destination. Note the permissions set on this folder (the part after 'ACL'). 
-Please look to the 'ACL' entry to see which permission 'rdms-testers' has in this folder. +$ ils -A /rug/home/Test_Team/folder_with_inheritance 
-# In this case, the permission level is 'own'.+        ACL - teamdrive-owner@rug.nl#rug:own   rdms-testers@rug.nl#rug:modify_object   g:Test_Team#rug:modify_object    
 +        Inheritance - Enabled 
 + 
 +# First, we 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 
 + 
 +Checking the permission shows that the permission of the parent folder are applied/inherited. Reason: 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 
 + 
 +# Now, we look at the permission of the second folder that we want to copy/move to show the effect of inheritance
 +# In this case, it is only a single user (rdms-testers@rug.nl) who has 'own' access on the folder
 $  ils -A folder_test $  ils -A folder_test
 /rug/home/rdms-testers@rug.nl/folder_test: /rug/home/rdms-testers@rug.nl/folder_test:
Line 55: Line 77:
  
 # The folder is now moved to a RDMS destination with permission inheritance enabled. # 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 $  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'+# We check now the permissions again. Even with enabled inheritance, the permissions of the original folder are kept. ReasonMoving data does not count as new data --> Inheritance is not applied. Note that only rdms-testers@rug.nl has own permission. These are the original permissions before the move!
-Even with enabled inheritance, the permissions of the original folder are kept.  +
-# MoveDoes not count as new data --> Inheritance is not applied.+
 $ ils -A /rug/home/Test_Team/folder_with_inheritance/folder_test $ ils -A /rug/home/Test_Team/folder_with_inheritance/folder_test
 /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            ACL - rdms-testers@rug.nl#rug:own   
         Inheritance - Disabled         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 
 </code> </code>
  
Line 94: Line 100:
         Inheritance - Enabled         Inheritance - Enabled
  
-# The 'rdms-testers@rug.nl' user uploads a new file from the local system to the RDMS 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_with_inheritance   $ iput test.txt /rug/home/Test_Team/folder_with_inheritance  
  
-# See the 'ACL' entry to verify the permission level of 'rdms-testers' +# See the 'ACL' entry to verify the permission level of 'rdms-testers'. 
-# Permissions on the newly uploaded file show that it inherited the permission from the parent collection automatically+# 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 $ ils -A /rug/home/Test_Team/folder_with_inheritance/test.txt
   /rug/home/Test_Team/folder_with_inheritance/test.txt   /rug/home/Test_Team/folder_with_inheritance/test.txt
Line 121: Line 127:
         Inheritance - Disabled         Inheritance - Disabled
  
-# The 'rdms-testers@rug.nl' user uploads a new file from the local system to the RDMS 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   $ iput test.txt /rug/home/Test_Team/folder_without_inheritance  
  
-# See the 'ACL' entry to verify the permission level of 'rdms-testers' +# See the 'ACL' entry to verify the permission level of 'rdms-testers'. 
-# Permissions on the newly uploaded file show that it only has one permission: own for the uploading user+# Permissions on the newly uploaded file show that it only has one permission: 'ownfor the uploading user (creator).
 $ ils -A /rug/home/Test_Team/folder_without_inheritance/test.txt $ ils -A /rug/home/Test_Team/folder_without_inheritance/test.txt
   /rug/home/Test_Team/folder_without_inheritance/test.txt   /rug/home/Test_Team/folder_without_inheritance/test.txt