Shared Group Directory: umask, Stale Group Membership, and Default ACLs
A shared project directory /srv/collab is owned by root:devteam with mode 2775. alice and bob are both members of devteam as a supplementary group; carol was added to devteam at 09:00 today. alice sets umask 002 in ~/.bashrc and her new files appear as -rw-rw-r-- alice devteam. bob uses the default umask and his files appear as -rw-r--r-- bob devteam. alice reports she cannot save changes to a file bob created in /srv/collab, even though both are in devteam. carol, who has been logged in over SSH since 08:00, gets 'Permission denied' creating any file there, and insists that usermod -aG devteam carol was run and confirmed with id carol. No ACLs are currently in use and no filesystem is mounted nosuid or with ACL support disabled.
1. Explain the two separate failures (alice/bob and carol) and state which command output would confirm each diagnosis.
Read the worked answer
They are unrelated problems that happen to produce the same error text.
alice/bob: file mode is decided at creation time.
The setgid bit on /srv/collab forces the group owner of new files to be devteam, but it does not touch the permission bits. Those come from the mode the program requests (0666 for a normal file) masked by the creating process's umask. bob's umask is 022, so his file is -rw-r--r-- and the group write bit never exists - alice cannot write it no matter what groups she is in.
Confirm with:
umask # as bob
ls -l /srv/collab # look at the group write bit, not the group name
carol: supplementary groups are fixed at login.
The kernel attaches a process's group list when the session starts. usermod -aG edits /etc/group only; carol's already-running shell and sshd session keep the old list. id carol run by root reads the files (and shows the change), while id inside carol's session shows the stale list - which is why her check 'passed' and her writes still fail.
Confirm with:
id # in carol's shell: no devteam
id carol # as root: devteam present
getent group devteam
2. How do you get carol working without asking her to log out, and what are the limits of that approach?
Read the worked answer
Her running shell's group list cannot be changed from outside - there is no supported way for root to rewrite another process's supplementary groups.
The practical options, in order of preference:
- A new session. Any new SSH login,
su - carol, or console login picks up the current /etc/group and simply works. This is what to check first; it proves the account change is fine. newgrp devteamin her existing shell. This starts a subshell whose primary group is devteam, so files she creates get group devteam and the group permission bits apply. It is not the same as having devteam as a supplementary group - commands that need the group but run outside the subshell will not see it, and exiting the subshell returns to the old state.
Do not try to fix it with chgrp, chmod o+w, or 777 - those hide a stale session and leave the directory less safe.
Verification inside her shell: id must list devteam before she retries the write.
3. The team wants every new file under /srv/collab to be group-writable regardless of each user's umask, without editing anybody's shell profile. Give the configuration, the commands to verify it, and explain why this works.
Read the worked answer
Use a default ACL on the directory. It is a property of the directory, so it applies to everyone, and it does not depend on the users' environment.
# default entries for future files/dirs, plus access entries for the existing tree
setfacl -d -m g:devteam:rwx /srv/collab
setfacl -R -m g:devteam:rwx /srv/collab # existing content
getfacl /srv/collab # shows entries starting with 'default:'
Why it works: when a directory carries a default ACL, the permissions of a newly created entry are derived from the default ACL intersected with the mode the program requested - the process umask is not applied. A program asking for 0666 in that directory therefore ends up with group rw, even for bob's umask 022 session. New subdirectories also inherit the default entries, so the rule propagates down the tree.
Points of judgement:
- This covers files created inside /srv/collab. Moving a file in from elsewhere with
mvkeeps its original mode and ACL; check withgetfaclafterwards. - The setgid bit already present is still needed - it is what makes the group owner
devteamrather than the creator's primary group. - Verify from a real user account, e.g.
su - bob -c 'touch /srv/collab/x && ls -l /srv/collab/x', rather than trusting the ACL listing alone.