When chmod 2775 Turns Into a Security Hole: Fixing Setgid Misconfigurations on /srv/shared

Understanding the 2775 Permission Set

The octal mode 2775 is the go‑to for giving a directory shared write access while keeping new files in the same group.

• 2 – set‑gid bit: new files inherit the directory’s group.
• 7 – owner gets rwx.
• 7 – group gets rwx.
• 5 – others get r-x.

On a path like /srv/shared it looks tidy: any member of the group can drop files, and those files stay in the same group for later collaboration. The flip side? Group write is a double‑edged sword. If the group contains people you don’t fully trust, or if the directory is exposed to a wider audience, the set‑gid bit can become a vector for privilege escalation or accidental data exposure.

When Set‑GID Becomes a Security Hole

The set‑gid bit itself is harmless; the danger shows up when you combine it with:

1. Group write permission (g+w).
2. Unrestricted group membership.
3. No extra controls (ACLs, SELinux, AppArmor, or file‑level permissions).

Think of a shared directory on an NFS or Samba share. If the group shared includes developers, support staff, and a handful of privileged users, any member can overwrite or delete files that belong to others. Worse, if someone drops an executable script, it can be run by anyone who can read the file, slipping past the “least privilege” guardrails.

The set‑gid bit also forces new files to inherit the directory’s group, which can lock a file into a group that’s too permissive. Even if a user’s umask is restrictive, the group write flag stays on.

Real‑World Scenario: /srv/shared in a Small Company

$ ls -ld /srv/shared
drwxrwsr-x  5 alice shared 4096 Sep 10 10:00 /srv/shared

• Owner: alice (admin).
• Group: shared (12 users, including a junior dev and a system operator).
• Mode: 2775.

The directory is used for exchanging build artifacts. Every user can drop files, and the set‑gid bit keeps them in the shared group. At first glance, this seems fine. But a quick audit shows:

$ getfacl /srv/shared
# file: /srv/shared
# owner: alice
# group: shared
user::rwx
group::rwx
other::r-x

No ACLs, no restrictions. If a user with a weak password logs in, they can:

• Overwrite a critical configuration file.
• Delete a file that a senior engineer is about to deploy.
• Drop a malicious binary that other users will execute.

Diagnosing Misconfigurations

1. Check the mode and set‑gid bit

   ls -ld /srv/shared
   

2. Inspect group membership

   getent group shared
   

3. Look for default ACLs

   getfacl /srv/shared
   

4. Audit recent changes

   auditctl -l | grep /srv/shared
   

5. Verify umask for users

   su - user1 -c 'umask'
   

6. Check SELinux or AppArmor contexts (if enabled)

   ls -Z /srv/shared
   

If any of these checks reveal overly permissive settings, you’re ready to tighten the configuration.

Fixing the Problem: Strategy Overview

There are several ways to keep the convenience of a shared directory while reducing the attack surface:

The most common compromise is to keep the set‑gid bit but restrict group write to a subset of users via ACLs.

Step‑by‑Step Fix: Restricting Group Write with ACLs

1. Ensure ACL support is enabled

   tune2fs -l /dev/sdX | grep 'Default mount options'
   

   If acl is missing, remount with acl or add it to /etc/fstab.

2. Set the directory mode to 2750

   chmod 2750 /srv/shared
   

   Now only the owner and the group have write access.

3. Grant write to specific users

   setfacl -m u:alice:rw /srv/shared
   setfacl -m u:bob:rw /srv/shared   # Bob is a trusted dev
   

4. Make ACLs default for new files

   setfacl -d -m u:alice:rw /srv/shared
   setfacl -d -m u:bob:rw /srv/shared
   

5. Verify

   getfacl /srv/shared
   

   Output should show explicit user entries and no group::rw line.

6. Test file creation

   su - bob -c 'touch /srv/shared/testfile'
   ls -l /srv/shared/testfile
   

   The file should belong to bob:shared and have rw-r-----.

Handling Existing Files

If the directory already contains files with permissive group write, you’ll want to audit and adjust them:

find /srv/shared -type f -perm -g+w -print0 | while IFS= read -r -d '' f; do
    echo "Fixing $f"
    chmod g-w "$f"
    chown :shared "$f"
    chmod 640 "$f"
done

This loop removes group write, forces the file into the shared group, and sets a conservative 640 mode.

A Few Extra Safeguards

• Use a dedicated group per project or team. It keeps the group write flag on a smaller, vetted set of users.
• Audit with auditd regularly. A simple rule like auditctl -w /srv/shared -p wa -k shared-dir will surface any write attempts.
• Keep SELinux or AppArmor enabled if your distro supports it. They add a second layer that can stop a rogue binary from doing anything useful.
• Rotate passwords and enforce MFA for accounts that can write to shared directories.

Tags

linux permissions security acl setgid shared-directory

See also

• How I Stopped Debian from Installing KDE Plasma During a System Upgrade – A Practical APT Pinning Example
• Fixing broken /etc/hosts entries after a Windows sync introduces stray CR characters
• Why Your systemd Service Stays “activating” After a Kernel Upgrade – A Step‑by‑Step Fix​
• Taming the DNS Resolver: Mastering resolvectl for Faster and More Reliable Internet Connections
• Taming Duplicate Entries in Your Bash History with a Simple Script