DartFS Lab Permissions

This is more information about DartFS permissions than most people will ever want to learn. We are happy to set up permissions for you if you don't want to delve into this. Email us at Research.Computing@dartmouth.edu

For those who value being capable and informed in this domain, read on!

• Permission Vocabulary
• Best Practices
• Traverse Checking
• Groups (Active Directory Security Groups)
• Manage your Lab's Groups
• Customizing to fit *your* needs
• Example Lab Layouts
• HPC Home Directories

Permission Vocabulary

If you are familiar with how Windows NTFS permissions work, these are (almost) exactly the same thing.  Every file or directory has it’s own Access Control List (ACL).  An ACL is a list of Access Control Entries (ACE).  Each ACE defines what kind of access (read-only, read-write, etc.) a *single* user or group has to that file/directory.

So an ACE gives permissions to a specific user or group and an ACL is the collection of all ACEs for a specific file or directory.

Inheritance is another crucial concept.  ACEs on a directory can be flagged so they are inherited by files and/or sub-directories created within it.

Best Practices

This is an incredibly flexible architecture which means it can be incredibly confusing.  To keep things manageable we strongly recommend two best practices.

1. Use group (not user) permissions.  Create groups, put people into those groups, and then give the groups permission (an ACE) to directories.  It might seem simpler to give individual people their own ACE but that doesn’t scale well.  What happens is that to change anything you have to recursively crawl through files and directories to set an ACE on each file/directory individually.  That can take a very long time; sometimes hours or days for large directory trees.  Whereas adding someone to a group that already has the right ACE is instantaneous.  Similarly, if someone leaves it’s trivial to get the list of groups they belong to and modify those, but totally impractical to get a list of files to which they have access.
2. Use inheritance.  If newly created files and directories always inherit ACEs from the parent directory then you know that the permissions for everything inside a directory are the same as for the directory itself.  That’s so much easier to manage than an environment where ACEs might change anywhere inside a directory tree.  A useful corollary is that you almost never want to manually set an ACE on a file whereas you will frequently set new (group!) ACEs on new top level directories.

Obviously to make best use of these principals you’ll need to spend some time planning how to lay things out.   Trust us – it’s time well spent!  Near the bottom of this page we describe some example layouts.

Traverse Checking

A quick word on “traverse checking”.   If you are familiar with Windows file servers, you would expect that if a person has a read-only ACE on a file that they can *always* read that file.  DartFS has an additional restriction.  The person must also have at least “traverse” permission on every directory leading to the file in order to read it.  Typically, you would give the person (via a group permission!) read-only to all the intermediate directories.  Read-only includes traverse and also lets them list the directory contents.  It is possible to give only the traverse permission on intermediate directories.  In that case a graphical file browser won’t be able to load directory listings for the intermediate directories.  The only way for a person to get to a file beneath a directory like that is to know the exact path and jump directly to the file.

Groups (Active Directory Security Groups)

Security groups are simply sets of people who are members of an Active Directory Group.  Note that groups can be nested (be a member of other groups).  By default each DartFS lab volume comes with two groups already defined. By convention, all groups created for use in DartFS have the prefix "rc-".  Lets use a lab called LabName as an example.

• rc-LabName-admin
  • This is the administrative group for your lab. Be very careful who you add to rc-LabName-admin.
  • This group has an inheritable full control ACE on everything in your lab share. 
  • Members of this group can manage the Active Directory security groups set up for the lab (rc-LabName-customname). 
  • Default members: the lab owner, rc-dartfsadmin
    • The “people” in rc-dartfsadmin are actually highly protected administrative service accounts and are what Research Computing admins would use if you need us to get in and help you.
• rc-LabName 
  • Typically we suggest putting everyone affiliated with the lab into rc-LabName.
  • This group has a non-inheritable read-write ACE at the top level. 
  • This lets them into the top level (remember traverse checking) and allows them to create files and directories there.  Only they (and people in the admin group) will be able to read/write the new files and directories. To change that, you need to change the ACEs.
    • Please note: by default the ACE for rc-LabName is not inherited when you create new files or directories. Yes, we broke from Best Practice 2 but we did it for a good reason.  If a new top level file or directory is created we want that to be private by default. This is simply more secure than the reverse.
• Any other groups you ask us to create.
  • Contact Research.Computing@dartmouth.edu if you need additional groups created or if you need assistance modifying the permissions of a group. 

Manage your Lab's Groups

After you SSH into one of the HPCs, you'll be able to run two different commands that will allow you to manage memberships to your Lab's access groups. 

• listADgroup
  • Lists the members of the group as well as some of their directory information.  Adding option "-R" will recursively list any nested groups.
• modifyADgroup
  • Allows you to add or remove members to a group. 

Customizing to fit *your* needs

You don’t have to leave things this way!  You can change ACEs to meet your needs and you can have as many additional groups as you want.  You do have to ask us to create groups but once created we can delegate management of the group members to you.

Changing ACLs:  There is a specific permission that lets someone change permissions.   rc-LabName-admin has this.   Typically we’d suggest nothing else have it.  Note that the person who actually creates a file or directory implicitly has the “change permission” permission too.   If you’ve laid things out correctly “regular users” shouldn’t be changing permissions.  It can be a security problem.  In fact protecting against those security issues is the primary reason for the traverse checking mentioned earlier.   The mechanics for changing ACLs are described in another document.

Modifying Group memberships: rc-LabName-admin is also given permission to manage the group memberships for all your groups.  The mechanics for managing group memberships are described in another document.

Example Lab Layouts

People based:  You want every person in your lab to have their own directory.  They should have read-write in there.  This is a case where breaking Best Practice 1 is okay and you would give each person their own (non-group) ACE on their own directory.  Maybe you want everyone else in the lab to have read-only access to the personal directories.  You could do that with a read-only ACE for the rc-LabName group.  Or get a new group for this if that seems more appropriate.

Project based:  You have three projects with different groups of people working on them.  Ask us to create a group for each project.  Put the right people into each group.  Create a directory for each project.  Assign the appropriate group ACE to each project directory.  Maybe you need a read-only group and a read-write group for each project?  No problem, we can do that too.

Trust based:  It’s a small stable group and you want everyone to have read-write everywhere.  Just change the ACE for rc-LabName to be inheritable.

HPC Home Directories

When you ssh into one of the Linux systems that Research Computing maintains, your home directory is part of DartFS.  Everything we have talked about on this page could also apply to home directories but by default there is a major difference.

The ACL on the top level of a home directory doesn’t have any inheritable ACEs.  That means everything in your home directory will have what we call POSIX mode bits (real drwxr-xr-x stuff) instead of an NTFS-style ACL.  There are times when this simply behaves better with traditional Linux tools. You can easily create ACLs in your home directory but once in place they can only be removed by an admin on the file server.  It’s a manually intensive and disruptive process so we strongly suggest not making ACLs in your home directory unless you’re sure that’s what you want.

If, however, you want to remove the ACL from directory or two in a lab volume (i.e. have POSIX mode bits) then please ask.  It’s hardly your fault the lab volume came with ACLs when you got it.  :-)