Advanced information on file permissions related to project spaces

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.