A shared folder that behaves.
SGID, the sticky bit, and special permissions.

New files in the webteam’s shared directory keep landing with the wrong group, and members keep deleting each other’s work. The fix is two special permission bits, and knowing why the default setup fails.

The ticket: the webteam needs a shared folder at /srv/webcontent. Every time someone creates a file it gets that user’s primary group instead of webteam, so the next person cannot write to it. On top of that, members keep deleting each other’s files. Current members are root and student, with dev1 and dev2 to be added once it works.

The real problem: the naive 775 directory looks right but is missing two special permission bits. Once you know which two, the fix is one chmod.

What we are doing: file permissions, octal versus symbolic notation, and the three special bits, SUID, SGID, and sticky, built into a working collaboration directory.

The ticket

Confirm the group and the users before you start.

getent group webteam   # GID 6000, members root and student
id student             # already in webteam
id webadmin            # the requester

Concept review. Octal and the special bits.

Read the two manual pages, then lock in the octal table and the special bits.

man chmod
man chown

The normal three permission digits are owner, group, other, each a sum of read 4, write 2, execute 1. So 7 is rwx, 6 is rw, 5 is r-x, 4 is r, 0 is nothing.

There is a fourth digit that goes in front, and two of its values are exactly what this ticket needs.

SUID  (4)  on an executable, it runs as the file's OWNER. e.g. /usr/bin/passwd runs as root
SGID  (2)  on a directory, new files inherit the directory's GROUP   <- fixes the group problem
sticky(1)  on a directory, only a file's owner can delete it          <- stops cross-deletion

Reading ls -l: an s in the group execute slot is SGID, a t in the other execute slot is sticky. An uppercase S or T means the special bit is set but the underlying execute bit is not, which is usually a mistake.

Diagnose the broken setup first

Reproduce the bug before you fix it. New files inherit the creator’s primary group, not the directory’s group, so student’s file comes out owned by student.

sudo mkdir /srv/webcontent_broken
sudo chown root:webteam /srv/webcontent_broken
sudo chmod 775 /srv/webcontent_broken
ls -ld /srv/webcontent_broken    # drwxrwxr-x, no SGID, no sticky

sudo -u student touch /srv/webcontent_broken/student_file.html
ls -l /srv/webcontent_broken/    # group is 'student', not 'webteam'. that is the bug

Build the directory correctly

SGID is the 2 in front. 2775 gives you SGID plus rwxrwxr-x, so new files inherit the directory’s group.

sudo mkdir /srv/webcontent
sudo chown root:webteam /srv/webcontent
sudo chmod 2775 /srv/webcontent
ls -ld /srv/webcontent    # drwxrwsr-x, the 's' in group execute is SGID

sudo -u student touch /srv/webcontent/student_correct.html
ls -l /srv/webcontent/    # group is 'webteam' now. SGID worked

Add the sticky bit

Without the sticky bit, any member can delete any file in the directory. The sticky bit restricts deletion to each file’s owner. Add it on its own, or set both bits at once with a leading 3.

# add it to the existing directory
sudo chmod +t /srv/webcontent
ls -ld /srv/webcontent    # drwxrwsr-t, the 't' is the sticky bit

# or set SGID and sticky together from the start
sudo chmod 3775 /srv/webcontent    # 3 = SGID + sticky

Add the users the right way

webadmin asked for dev1 and dev2 once it worked. The flag that matters is -a.

sudo usermod -aG webteam dev1
sudo usermod -aG webteam dev2
getent group webteam
id dev1

# prove the sticky bit works: dev2 cannot delete dev1's file
sudo -u dev1 touch /srv/webcontent/dev1_page.html
sudo -u dev2 rm /srv/webcontent/dev1_page.html    # Permission denied

Octal versus symbolic practice

Both notations show up on the exam. Octal sets the whole mode at once. Symbolic nudges individual bits.

sudo touch /tmp/perm_test
sudo chmod 644 /tmp/perm_test          # rw-r--r--
ls -l /tmp/perm_test

sudo chmod u+x,g-r,o= /tmp/perm_test   # add owner execute, drop group read, clear other
ls -l /tmp/perm_test

sudo chmod a+r /tmp/perm_test          # everyone gets read
ls -l /tmp/perm_test

Exam questions

Write the command first.

Q1. Set /srv/webcontent/index.html so the owner has read and write, the group has read, and others have nothing. Use octal.

Q2. Create /srv/devshare owned by group developers where all new files automatically inherit the developers group.

Q3. Create /srv/dropbox where any user can write files but nobody can delete anyone else’s.

Answers.

# A1
sudo touch /srv/webcontent/index.html
sudo chmod 640 /srv/webcontent/index.html    # -rw-r-----
# A2
sudo mkdir /srv/devshare
sudo chown root:developers /srv/devshare
sudo chmod 2775 /srv/devshare                # drwxrwsr-x
# A3
sudo mkdir /srv/dropbox
sudo chmod 1777 /srv/dropbox                 # drwxrwxrwt

Final checklist: confirm everything works

If every check passes, the ticket is done.

# 1. webcontent has SGID and sticky, owned by webteam
ls -ld /srv/webcontent    # expect drwxrwsr-t

# 2. new files inherit the webteam group
sudo -u student touch /srv/webcontent/check.html && ls -l /srv/webcontent/check.html

# 3. dev1 and dev2 are in webteam
id dev1; id dev2

# 4. a member cannot delete another member's file (sticky works)
# 5. all three exam commands written from scratch
# 6. tracker entry checked off

Reply to webadmin: /srv/webcontent is now drwxrwsr-t. SGID so new files inherit the webteam group, sticky so members cannot delete each other’s work. dev1 and dev2 added with usermod -aG so their other groups stayed intact.