RDS: How to control access for different members of a project
This guide describes how to set permissions on the Research Data Storage Service.
In RDSS there isn’t much that a PI can do that is privileged compared to the other members of the project group, except for choosing the project members. It is not possible to assign read only access to certain members at present.
This guide is aimed at...
The following applies to the SSH/SFTP storage (GPFS) facility:
The PI is made the owner of the project folder, so he/she can modify the permissions of this.
To go any further it will be necessary to explain a little bit about ownership in the context of our file system (POSIX compliant). A file (of which a directory is also a type) has three classes of ownership: user, group and other.
The ‘user’ is the person that created it (the UCL user name that you logged on with).
The ‘group’ ownership refers to a group with a name of a group like rd1234, which defines a list of users. Research Data Services creates a group for each new project. The groups are not just internal to the RDS system, but are recognized by other computer systems around UCL. A file only has one group owner, but a user can be a member of multiple groups. Sometimes this can create confusion when someone copies data into our system as it can be associated with the wrong group, making it hard to access by other members of the project. Group ownership can be changed by a user to any of the other groups for which he/she is a member. If you are using our service at the command line the command:
chgrp -R <desired group name> <directory name>
will change the group ownership of all of your files/directories under a given directory. WinSCP, has a way to do this with a Graphical User Interface, under ‘properties’ and other GUI based programs may also offer a way of changing group ownership. We tell you the group name for your project in the registration email, but it is also included in the name of the top level directory for your project which will be:
ritd-ag-project-<group name>-<UPI of PI>
‘Other’ refers to anyone that isn’t either the owner or in the group that the file belongs. You will probably not want to have any ‘other’ permissions set so that people from outside your group can’t see your work.
For each of these categories, read, write and execute permissions can be set. Write access includes the ability to delete a file. If a directory has executable permission, it means that the given user, group or other member can traverse into that directory and take actions on contents (subject to the permissions of said contents). A command called chmod can be used for modifying permissions at the command line or you can do this through WinSCP and FileZilla (probably other programs). If a regular file is executable, then it means is either a program or a human readable script that can be executed run by the server (we prefer for people to not run scripts on our service as it makes it run slower). If you are interested in carrying out manipulations like this, then you might want to read up on POSIX file permissions.
We have changed our policies in the past, but at present, when a new project is created we apply something called an ACL which causes new directories and files to have read and write access set for themselves and members of the group (also execute for directories). If a PI or another project member likes, they can modify the permissions of a directory that they create to remove execute and write permissions for the group. This will prevent anyone from their project from seeing inside or modifying the contents, so they could have their own private folder. If they want their fellow project members to be able to see but not modify their project contents then group-read/execute permissions will need setting on everything in the folder with write permissions disabled. Care should be taken as any new files created, will again have write permission set.
As the RDS team have root access, we can change anything permission or ownership related and can step in should users get in trouble. For changes that need to be made that affect the files of anyone other than the owner of those files, we will need the project PI or administrator’s permission by email.
The following applies to the iRODS facility:
There are a different set of permissions available in iRODS. In our implementation, by default, everything is shared within your project groups. We recommend that you don’t modify these as it may interfere with the way that automated systems manage your data. Additionally, the level of advice/tech support on these permissions that’s generally available on the internet is vastly less for iRODS than for POSIX (used by GPFS).
Related guides & other info
Help & Support
For further help and assistance you can contact email@example.com