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 [2024/09/03 08:42] – Updated the "null" text to reflect changes in iRODS 4.3 giuliordms:data:permissions [2025/12/11 13:56] (current) – [Inheritance] reworked text and added example use case giulio
Line 1: Line 1:
 ====== Permissions and Inheritance====== ====== Permissions and Inheritance======
  
-Within the RDMS, we support **four levels of permissions** or user privileges to files and folders that can be defined by the users.+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'. In an order of ascending privileges, these permissions are 'Null', 'Read', 'Read/Write' and 'Own'.
Line 8: Line 8:
  
 ^  Permission Level      ^  Read       ^  Modify          ^   Create New   ^   Delete   ^   Share   ^ ^  Permission Level      ^  Read       ^  Modify          ^   Create New   ^   Delete   ^   Share   ^
-|  **Null**    |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?20|}}     |   {{:rdms:data:1280px-eo_circle_red_blank.svg.png?20|}}  |   {{:rdms:data:1280px-eo_circle_red_blank.svg.png?20|}}  |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?20|}}   |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?20|}}        | +|  **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?20|}}     |   {{:rdms:data:1280px-eo_circle_red_blank.svg.png?20|}}  |   {{:rdms:data:1280px-eo_circle_red_blank.svg.png?20|}}  |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?20|}}   |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?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?20|}}     |  {{:rdms:data:eo_circle_green_checkmark.svg.png?20|}}   |  {{:rdms:data:eo_circle_green_checkmark.svg.png?20|}}  |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?20|}}   |  {{:rdms:data:1280px-eo_circle_red_blank.svg.png?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?20|}}     |  {{:rdms:data:eo_circle_green_checkmark.svg.png?20|}}   |  {{:rdms:data:eo_circle_green_checkmark.svg.png?20|}}  |  {{:rdms:data:eo_circle_green_checkmark.svg.png?20|}}    |  {{:rdms:data:eo_circle_green_checkmark.svg.png?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|}}   |
  
  
 And for a more detailed explanation of what this permissions mean:  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.+**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. +**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.+**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. **Note**: If you accidentally remove your own permissions, you will no longer be able to restore them even if you were the owner of the object. +**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** **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. 
-  * Previously, it was possible to restore your own permissions to an object, if you were owner of the object before. With the new update of the iRODS system, this is no longer possible. +  * 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.
  
-===== Inheritance =====+===== Permission Inheritance =====
  
-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. +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, but it can also be disabled on a per folder/collection basis.  +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 (see "future" screenshot).
-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. +
  
-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. +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.
 +
 +==== Example: Permission Inheritance - ON ====
 +
 +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.
 +
 +==== Example: Permission Inheritance - OFF ====
 +
 +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.