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 do not choose 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

If you are familiar with how Windows NTFS permissions work, these are (almost) exactly the same thing.  Every file or directory has its 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 user/group and an ACL is the collection of all ACEs for a specific file/directory.

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 you have to recursively crawl through files and directories to set the ACE on each file/directory individually.  That can take a very long time; sometimes hours for large directory trees.  Whereas adding someone to a group that already has the right ACE is instantaneous.  Similarly, it’s trivial to get the list of groups that a person belongs to, but impossible to get a list of files they have access to (short of checking every file individually).
  2. Use inheritance. Newly created files and directories inherit ACEs from the parent directory.  As long as you don’t override that, 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 a new (group!) ACEs on new top-level directories.

Obviously, to make the best use of these principles 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 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 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 groups of people.  Note that groups can also include other groups.  By default, each DartFS lab volume comes with two groups already defined.  Let’s use a lab called LabName as an example.

  • rc-LabName-admin – this group has full control ACE on everything.  This is the administrative group for your lab. Be very careful who you add to rc-LabName-admin.  The lab owner is a member, obviously, and so is the rc-dartfsadmin group.  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 – this group has a non-inheritable read-only ACE at the top level.  Typically we suggest putting absolutely everyone affiliated with the lab into rc-LabName.  This lets them into the top level (remember traverse checking) and then other ACEs can take over.  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.   Imagine the lab owner creating a “Personnel Recommendations” folder…
  • Any others you ask us to create.

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, this 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.

(Excessively?) 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 read-write and 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 a directory or two in a lab volume (i.e. have POSIX mode bits) then please ask.  It’s hardly your fault the lab volume had ACLs when you got it.  🙂