Skip to main content

Access Permissions & Directories

Data Depot is very flexible in the access permission models and directory structures it can support. New spaces on Data Depot are given a default access model and directory structure at setup time. This can be modified as needed to support your workflows.

Information follows about the default structure and common access models.

Default Configuration

This is what a default configuration looks like for a research group called "mylab":

/depot/mylab/
            +--apps/
            |
            +--data/
            |
            +--etc/
            |     +--bashrc
            |     +--cshrc
            |
 (other subdirectories)

The /depot/mylab/ directory is the main top-level directory for all your research group storage. All files are to be kept within one of the subdirectories of this, based on your specific access requirements. These subdirectories will be created after consulting with you as to exactly what you need.

By default,the following subdirectories, with the following access and use models, will be created. All of these details can be changed to suit the particular needs of your research group.

  • data/
    Intended for read and write use by a limited set of people chosen by the research group's managers.
    Restricted to not be readable or writable by anyone else.
    This is frequently used as an open space for storage of shared research data.
  • apps/
    Intended for write use by a limited set of people chosen by the research group's managers.
    Restricted to not be writable by anyone else.
    Allows read and execute by anyone who has access to any cluster queues owned by the research group and anyone who has other file permissions granted by the research group (such as "data" access above).
    This is frequently used as a space for central management of shared research applications.
  • etc/
    Intended for write use by a limited set of people chosen by the research group's managers (by default, the same as for "apps" above).
    Restricted to not be writable by anyone else.
    Allows read and execute by anyone who has access to any cluster queues owned by the research group and anyone who has other file permissions granted by the research group (such as "data" access above).
    This is frequently used as a space for central management of shared startup/login scripts, environment settings, aliases, etc.
  • etc/bashrc
    etc/cshrc
    Examples of group-wide shell startup files. Group members can source these from their own $HOME/.bashrc or $HOME/.cshrc files so they would automatically pick up changes to their environment needed to work with applications and data for the research group. There are more detailed instructions in these files on how to use them.
  • Additional subdirectories can be created as needed in the top and/or any of the lower levels. Just contact support and we will be happy to figure out what will work best for your needs.

Common Access Permission Scenarios

Depending on your research group's specific needs and preferred way of sharing, there are various permission models your Data Depot can be designed to reflect. Here are some common scenarios for access:

  • "We have privately shared data within the group and some software for use only by us and a few collaborators."
    Suggested implementation:
    Keep data in the data/ subdirectory and limit read and write access to select approved researchers.
    Keep applications (if any) in the apps/ subdirectory and limit write access to your developers and/or application stewards.
    Allow read/execute to apps/ by anyone in the larger research group with cluster queue access and approved collaborators.
  • "We have privately shared data within the group and some software which is needed by all cluster users (not just our group or known collaborators)."
    Suggested implementation:
    Keep data in the data/ subdirectory and limit read and write access to select approved researchers.
    Keep applications (if any) in the apps/ subdirectory and limit write access to your developers and/or application stewards.
    Allow read/execute to apps/ by anyone at all by opening read/execute permissions on your base Data Depot directory.
  • "We have a few different projects and only the PI and respective project members should have any access to files for each project."
    Suggested implementation:
    Create distinct subdirectories within your Data Depot base directory for each project and corresponding Unix groups for read/write access to each.
    Approve specific researchers for read and write access to only the projects they are working on.

Many variants and combinations of the above are also possible covering the range from "very restrictive" to "mostly open" in terms of both read and write access to each subdirectory within your Data Depot space. Your lab can sit down with our staff and explain your specific needs in human terms, and then we can help you implement those requirements in actual permissions and groups. Once the initial configuration is done, you will then be able to easily add or remove access for your people. If your needs change, just let us know and we can accommodate your new requirements as well.

Storage Access Unix Groups

To enable a wide variety of access permissions, users are assigned one or more auxiliary Unix groups. It is the combination of this Unix group membership and the r/w/x permission bits on subdirectories that allow fine-tuning who can and can not do what within specific areas of your Data Depot. These Unix groups will generally closely match the name of your Data Depot root directory and the name of the subdirectory to which write access is being given. For example, write access to /depot/mylab/data/ is controlled by membership in the mylab-data Unix group.

There is also one Unix group which has the name of the base directory of your Data Depot, mylab. This group serves to limit read/execute access to your base /depot/mylab/ directory and also helps to define the read/execute permissions of some of the subdirectories within. This Unix group is composed of the union of the following:

  • all members of your more specific Unix groups
  • all users authorized to access any of your research group's cluster queues
  • any other specific individuals you may have approved

Research group faculty and their designees may directly manage membership in these Unix groups, and by extension, the storage access permissions they grant, through the online web application.

Link to section 'Checking Your Group Membership' of 'Storage Access Unix Groups' Checking Your Group Membership

As a user you can check which groups you are a member of by issuing the groups command while logged into any RCAC resource. You can also look on the website at https://www.rcac.purdue.edu/account/groups.

$ groups
mylab mylab-apps mylab-data

If you have recently been added to a group you need to log out and then back in again before the permissions changes take effect.

Helpful?

Thanks for letting us know.

Please don't include any personal information in your comment. Maximum character limit is 250.
Characters left: 250
Thanks for your feedback.