RDV groups and permissions

The RDV 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. This is remarkably similar to the permissions structure used by RDSv2, and further documentation on this can be found there.

<unique_project_identifier>
Located in the /rdv/project/ area
# E.g. /rdv/project/Q5jpzqn0PlM

# Within your personal rdv directory, that is displayed as
<human_friendly_name>-<unique_project_identifier>
# E.g. biobank-sampledata-Q5jpzqn0PlM

We make heavy 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.

Project permission structure

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

E.g. rdv-Q5jpzqn0PlM-managers and rdv-Q5jpzqn0PlM-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. rdv-Q5jpzqn0PlM-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. rdv-Q5jpzqn0PlM-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. rdv-Q5jpzqn0PlM-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 rdv-Q5jpzqn0PlM-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 /rdv/project/Q5jpzqn0PlM

# file: /rdv/project/Q5jpzqn0PlM
# owner: root
# group: rdv-Q5jpzqn0PlM-managers
# flags: -s-
user::rwx
group::rwx
group:rdv-Q5jpzqn0PlM-users:r-x
group:rdv-Q5jpzqn0PlM-visitor:r-x
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:group:rdv-Q5jpzqn0PlM-managers:rwx
default:group:rdv-Q5jpzqn0PlM-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:rdv-Q5jpzqn0PlM-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 /rdv/project/Q5jpzqn0PlM/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 /rdv/project/Q5jpzqn0PlM/results/current/