RDS groups and permissions¶

The RDS storage platform relies on standard POSIX permissions to control who can read or write to a directory or file. This allows it’s owner to decide whether to allow other users access, and on what basis. Alongside this we have a concept of project ‘managers’ and project ‘users’, who are defined by the PI and any people they delegate the permission to, via the self-service storage portal. Managers can ask us to change permissions on particular files, if there are problems that need fixing. E.g. the user who created a file has left the project and the manager needs to regain access to it, etc.

In the last few years, we made a change to give managers more direct control over their data. This applies to newly created projects, as well as any which have subsequently been migrated to newer hardware. To help users identify whether they are working with the newer or older project type, the name has a different format on the filesystem. Unfortunately, the storage portal isn’t currently able to show this distinction.

Newer projects (which we are calling ‘version 2’ or RDSv2) use the format;

rds-<unique_project_identifier>
Located in the /rds/project/ area
# E.g. /rds/project/rds-LWK1fGimSv0

# Within your personal rds directory, that is displayed as
rds-<project_name>-<unique_project_identifier>
# E.g. rds-biobank-sampledata-LWK1fGimSv0

Older projects (which we are calling ‘version 1’ or RDSv1) use the format;

rds-<PI_name>-<project_name>
Located in a directory named for the PI
# E.g. /rds/project/ab123/rds-ab123-biobank-sampledata
# Which would appear as rds-ab123-biobank-sampledata in your personal rds directory

Newer projects ‘RDSv2’ make use of Access Control Lists (ACL’s), which are extra permissions that work alongside and can override the standard POSIX ones. It’s possible to setup quite complicated permission structures, but we use this to set some basic defaults and allow managers full access to their data without needing to request changes via the servicedesk.

Recent project (RDS version 2) structure¶

Projects have two active groups associated with them, a ‘managers’ and ‘users’ one:

E.g. rds-LWK1fGimSv0-managers and rds-LWK1fGimSv0-users

These are populated by the project settings in the self-service portal, the data owner, data managers and project managers are members of the ‘managers’ group, users are members of the ‘users’ group.

An extra ‘visitors’ group (e.g. rds-LWK1fGimSv0-visitors) is also present by default and may be seen in the output from some commands, this has no members but is available if managers need a way to give very limited access to a set of users. E.g. an external collaborator who should be allowed read-only access to a single directory.

When a new project is created, some default ACLs are set. These give the following permissions;

Managers - read/write access to all data, able to create new directories at the top level of the project.
Users - read-only access to data, no ability to create new directories.
Visitors - read-only access to files placed at the top level of the project, no access to any other data.

When a manager creates a new directory at the top level of the project, as normal they will become it’s owner and the group ownership will be the managers group (e.g. rds-LWK1fGimSv0-managers). However the ACLs mean that users will also have read-only access to it and any subsequent data stored under it. Users can be given full read/write access by changing the group ownership to the users group (e.g. rds-LWK1fGimSv0-users).

For a new project, managers will first need to create the required top level directories and then give users full access by changing the group ownership, as required.

$ mkdir data
$ mkdir results
$ mkdir users
$ chgrp rds-LWK1fGimSv0-users data results users

Reading/modifying ACLs - if desired¶

In most cases, there is no need to view or change the default ACLs. However managers do have the ability to set extra ACLs or modify the existing ones if they wish. The standard linux commands getfacl and setfacl are used to do this.

# Viewing the ACLs of the projects top level directory
$ getfacl /rds/project/rds-LWK1fGimSv0

# file: /rds/project/rds-LWK1fGimSv0
# owner: root
# group: rds-LWK1fGimSv0-managers
# flags: -s-
user::rwx
group::rwx
group:rds-LWK1fGimSv0-users:r-x
group:rds-LWK1fGimSv0-visitor:r-x
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:rds-LWK1fGimSv0-managers:rwx
default:group:rds-LWK1fGimSv0-users:r-x
default:mask::rwx
default:other::---

This shows the directory is read/write ‘rwx’ for the owner and group (managers in this case), with read-only ‘r-x’ access for users and the empty visitors groups. The lines starting with default: are the permissions which any new directory created will inherit. In this case, that managers will have read/write access and users read-only. If the directory group ownership has been changed with chgrp as above, then users will have full read/write access to this and any newly created files or directories.

Setting or modifying ACLs can be done using setfacl, it is worth reading the documentation to see the options available and RedHat also have a helpful guide - https://www.redhat.com/sysadmin/linux-access-control-lists

setfacl -m (meaning modify the ACL) [group:user]:[user or group name]:[permission to set] filename

# E.g. giving all users read/write access to a single file, without changing the owner or group.
$ setfacl -m g:rds-LWK1fGimSv0-users:rw CollectionLog.txt

# E.g. giving the user ab123 read-only access to a directory and it's contents, but not any files created subsequently.
$ setfacl -R -m u:ab123:rx /rds/project/rds-LWK1fGimSv0/results/current/

# E.g. giving the user ab123 read-only access to a directory and contents, as well as any future files and directories created.
# The extra `d:` means set the default ACL which applies to any newly created items.
$ setfacl -R -m u:ab123:rx -m d:u:ab123:rx /rds/project/rds-LWK1fGimSv0/results/current/

Legacy project (RDS version 1) structure¶

There are no ACLs set by default for these projects, managers and users have the same access to data based on the ownership and POSIX permissions.

All project members are part of a single group e.g. rds-ab123-biobank-sampledata and files/directories within the project should have their group ownership set as this. Access by other members of the project can be granted or removed by giving the project group the appropriate permissions using the chmod command.

# To grant access by the rest of the project to a directory and it's contents
$ chmod -R g+rwx /rds/project/ab123/rds-ab123-biobank-sampledata

# To remove access by the rest of the project to a directory
$ chmod g-rwx /rds/project/ab123/rds-ab123-biobank-sampledata