iCE project space and collections

In any iCE project the following policies are applied by default:

• all members of the project have read/write/execute rights within that iCE project
• no home directory is provided to members
• inheritance at the project directory level is on by default
• non project members do not have any access to the project directories

When you login to iCE, you get access to a shared space where 'all' project members have equal permissions. The CO admin does not have any additional privileges when working with iCommands, this is only the case in the SRAM portal.

In iCE there is the option to create directories (collections) with specific rights to users and/or to groups of users. In the next section we will provide some scenarios of group management and examples of how to assign permissions.

iRODS permission model

Typically, we are used to access models with rwx permissions. In iRODS, metadata can also be added to the data by the users to maintain data provenance. Additional permissions relating to metadata result in the application of a 10-layer permission model:

1. own
2. delete_object
3. write, modify_object
4. create_object
5. delete_metadata
6. modify_metadata
7. create_metadata
8. read, read_object
9. read_metadata
10. null

Each layer includes the permissions in the layer below. You can find more details of the iRODS permissions layer here.

Group management scenarios and examples

Data access permissions based on groups created in SRAM

To better explain Group Management on iCE we will go through a hypothetical scenario where an iCE project called ice-poc-surf, responsible for an organisation's ETL pipeline, has three groups of users: ice-extract-group, ice-transform-group, ice-load-group.

iCE project name: ice-poc-surf

If you are an administrator and you want to create groups and/or assign users to groups via the SRAM portal please check here. If you are an iCE project member and you want to be part of a specific group please contact your CO administrator.

If you want to check at any given time in which groups your account belongs you can execute the iuserinfo command as in the example below.

$ iuserinfo
name: member1
id: 50918
type: rodsuser
zone: snow
info: 
comment: 
create time: 01676981664: 2023-02-21.12:14:24
modify time: 01676981664: 2023-02-21.12:14:24
member of group: member5
member of group: icepocsurf
member of group: icepocsurf.ice-extract-group
member of group: icepocsurf.ice-load-group
member of group: public

How do I create a directory with read-only for all users and write for specific users/groups?

Based on our hypothetical scenario, we would like to have a directory (collection) in which all users will have read-only access and the members of the ice-extraction-group will be able to add the raw files they gather from their data acquisition pipeline.

To do that we execute the following commands after logging into iCE:

$ imkdir extraction-dir
$ ichmod -r read icepocsurf extraction-dir
$ ichmod -r write icepocsurf.ice-extract-group extraction-dir

In the above commands, we first create a directory called extraction_dir. Then we give read permission to every member of the project, thus to the project's main group icepocsurf. And finally, we give write permissions to the members of ice-extract-group (member1, member2, member5).

Similarly, we would like to have a directory (collection) in which all users will have read-only access and the members of the ice-transform-group will be able to edit and create files after curating the original raw files from the extraction-dir.

$ imkdir transformation-dir
$ ichmod -r read icepocsurf transformation-dir
$ ichmod -r write icepocsurf.ice-transform-group transformation-dir

How do I create a directory with specific permissions for specific members/groups?

Now, after the extraction and the transformation steps are completed inside the organisation, there is a need for a directory where the load and analysis step of the ETL will take place.

In this hypothetical scenario we have the requirement that only the ice-load-group should be able to have read-access to the directory, and only member3 (the team leader of the transformation group) will have write access to deliver the final output files.

As mentioned in the beginning, one of the default group management and permission policies is that inheritance at the project directory level is on by default. This means that the new directory load-dir we are going to create will give read/write access to all members of icepocsurf group by default, thus to every member of the project.

So, in order to achieve the requirement set in the above scenario we will have to remove the icepocsurf group completely. Then give read-only access to all members of the ice-load-group, and finally give write access only to member3:

$ imkdir load-dir
$ ichmod -r null icepocsurf load-dir
$ ichmod -r read icepocsurf.ice-load-group load-dir
$ ichmod -r write member3 load-dir

What happens if the only group with access to a collection is deleted? 

Suppose a new collection is setup such that only a single group has access. If this group is deleted, ownership will be automatically provided back to the CO group, which includes all members of the project. While this prevents collections from becoming orphaned, users should be aware that there is potential to expose data accidentally and they should act accordingly (i.e., give access to a different group/user, or delete the data before removing the group).