Advanced information on file permissions related to project spaces

[wwarriner]

What would you like to see added?

I was working on ticket RITM0639280 and I got tired of not understanding how file permissions were affected by interactions between various methods of moving data around, and parent directory permissions, setgid, and ACLs, so I wrote a script to test (which I will upload to github later on). I've also included results from tree -gpu in a separate results file. Both are attached.

My takeaway is that the following makes for a decent default configuration for project directories where every group member should have equivalent access. This is viewed with getfacl.

# file: data/project/...
# owner: $owner
# group: rc-datasci
# flags: -s-
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---

The configuration above can be achieved with

chmod 770 "$DIR"
chmod g+s "$DIR"
setfacl --set u::rwx,g::rwx,o::- "$DIR"
setfacl -d --set u::rwx,g::rwx,o::- "$DIR"

Takeaways:

• We need the default ACLs to ensure new files and directories correctly inherit permissions and ACLs.
• If we use the ACL mask to knock out x, then subdirectories aren't traversable by group members. If we don't use it, then all copied files are executable. There doesn't seem to be a happy middle ground with different behaviors for directories and files. Do you have any thoughts @mhanby?
• mv and the -a (archive) and -p (preserve) flags for most transfer methods don't respect target directory permissions and ACLs.
• rclone copy does the secure thing and strips x permission from files, while otherwise respecting ACLs.

Responses

Quick commnet re: scp and rsync, if your source and dest are localhost, then the hostname is optional.

scp ./somefile ./somefile.copy
rsync ./somefile ./somefile.copy2

if we use the ACL mask to knock out x, then subdirectories aren't traversable by group members. If we don't use it, then all copied files are executable. There doesn't seem to be a happy middle ground with different behaviors for directories and files.

Unfortunately, no. Having all files executable would not be good, however.

[wwarriner]

Taken from a previous ticket

I've been working on finding a solution. We need two pieces: (1) fix the current issue and (2) prevent it from reoccurring as best we can. I've got something for (2), in the form of an ideal configuration of permissions and Access Control Lists (ACLs).

To resolve the issue, I think we need to apply the following block to every directory in the project directory, recursively. We can talk about how to do this a little later, because we need to do some information gathering first to ensure we don't inadvertently destroy any special cases that already exist.

For directory $DIR, the configuration can be achieved as follows:

chmod 770 "$DIR"
chmod g+s "$DIR"
setfacl --set u::rwx,g::rwx,o::- "$DIR"
setfacl -d --set u::rwx,g::rwx,o::- "$DIR"

• The first line sets the permission so only the owner and group members can access, and have full read, write, execute permissions.
• The second line sets the setgid bit, which ensures that directories and files created within $DIR have the same group owner as $DIR. This applies recursively.
• The third line sets the ACLs to be the same as the permissions. This ensures that newly created files share the same permissions as $DIR.
• The fourth line sets the ACL defaults to be the same. This ensures that newly created files share the same ACLs (and defaults) as $DIR.
• Lines 2, 3, 4 together ensure that everything that gets added to $DIR will have the same permissions as $DIR.

But there is a wrinkle. Different data transfer methods produce different results. Anything respecting ACLs will behave the way you'd like.

• cp precisely follows ACLs and setgid, so this should behave as expected.
• cp -a and cp -p ignore ACLs and setgid, steer group members away from these two flags.
• scp and rsync both behave like cp.
• rclone copy precisely follows ACLs and setgid for directories. It also follows ACLs for files, except it turns off x execute permissions.
• mv totally ignores ACLs and setgid, steer group members away. If you need the same behavior but respecting ACLs, use anything that works like cp or rclone copy, followed by rm -r (carefully) on the source.
• mkdir and touch follow ACLs and mkdir follows setgid. I imagine that software creating totally new files and directories will behave the same way. Note that touch does not turn on the x execute bit by default.
• I haven't tested Globus, but I have every reason to believe it will respect ACLs and setgid.
• Long-Term Storage (LTS) is S3 compatible, so it has a totally different concept of access control than Linux. As a result, any software interacting with S3 should respect ACLs, as it would be creating "new" files and directories. This includes awscli, s3cmd, s5cmd. It also includes Globus and rclone when interacting with LTS or AWS.

One important note: rclone copy and Globus (both involving only Linux, not S3) can be made to copy the original file attributes, including permissions and owner. If these options are used, they will ignore ACLs and possibly setgid.

Returning to the topic of fixing existing permissions, it is possible to do this with a script that recursively walks the directory tree of the project space, and applies the four shell code lines from earlier. We can do this as root, ignoring existing ownership. We can also change ownership, as needed. However, if we apply the same permissions and ACLs to all directories incautiously, we could potentially allow researchers to access data they couldn't before. So we need to know if there are any subdirectories of the projectspace to leave alone.

What we'd need is some combination of lists with "yes, fix these directory recursively" and "no, leave these directories alone".