Shared finance directory, default ACLs and a setuid import script

Base file mode is 0666 for a normal file, then the umask is applied: 0666 & ~0022 = 0644. That is rw- for the owner and r-- for group and others. Alice's file is -rw-r--r-- alice finance, exactly as observed; bob can read but not write.

The setgid bit on /srv/finance does two things: new files inherit the directory's group, finance, and new subdirectories inherit setgid. It does not add group write permission. Group ownership is correct; the permission bits are not.

The command setfacl -m g:finance:rwx /srv/finance sets an access ACL on the directory itself. It does not propagate to files created later. Propagation requires a default ACL, setfacl -d -m g:finance:rwx /srv/finance, which is copied into the ACL of each new file and directory. Without -d, the only effect is on access to the directory, not on its new contents. Also remember that the ACL mask caps effective permissions, so getfacl should be checked after the change.

Least-privilege setup:

# group collaboration, inherited by new files and directories
setfacl -d -m g:finance:rwx /srv/finance
setfacl -m g:finance:rwx /srv/finance
# fix existing files if appropriate
setfacl -R -m g:finance:rwX /srv/finance

The default ACL gives new files a group entry of rwx and a mask; because regular files are created without execute permission, the effective group permission on a regular file will be rw-. Execute is only meaningful for directories or scripts. Existing files need a one-time recursive ACL; capital X grants execute only where it is already set or where the target is a directory.

Trade-offs:

• Default ACL is per-directory and survives users with different umasks; it is the better fit for a shared project tree. It can be modified by a later chmod on the file, which recalculates the mask, so users can still accidentally remove group access.
• umask 0002 in a shared shell profile is simpler but global to the user's session; it also makes all new files group-writable everywhere, not just in /srv/finance. It does not help files created by services or by users who have not sourced the profile.

Use the default ACL, keep the setgid bit for group inheritance, and audit with getfacl.

Three independent reasons the setuid plan fails or is unsafe.

1. Linux ignores setuid on interpreted scripts. The kernel honors the setuid bit only on ELF binaries. For a script, the interpreter is executed and the script is passed as an argument; the setuid bit on the script is not applied. Mode 4755 shows in ls, but the process runs as the calling user, not root.
2. nosuid. The script is on an NFS mount exported with nosuid, so even an ELF setuid binary there would not gain privilege. mount would show nosuid; moving the binary to a local filesystem would be required, but that does not fix the shell-script problem.
3. Argument injection. Even a working privileged wrapper that invokes /bin/bash with caller-supplied arguments is dangerous. A caller can pass -c, redirections or environment variables such as BASH_ENV and obtain a root shell. Environment variables must be cleared and arguments validated against a strict allowlist.

Safer mechanism: keep import.sh root-owned and not writable by finance, and grant a narrowly scoped sudo rule:

%finance ALL=(root) /usr/local/bin/import.sh

The script must not trust its arguments; validate them, use absolute paths and avoid passing them to a shell. If the tool needs more than a fixed command, write a small compiled helper instead of a shell script. Verify with sudo -l as a finance user.