Several engineers share a directory owned by the group `devs`, but files each of them creates come out owned by that person's own primary group, so their colleagues cannot write them. What does setting the set-group-ID bit on the directory change, and what does it deliberately not change?
answer
- group comes from the parent, not the creator
- the s sits in the group column
- inheritance also copies the bit down
- ownership fixed, permissions still not
- leading 2 in the octal mode
basics
~20 sA set-group-ID directory makes new entries inherit the directory's group instead of the creator's primary group, and new subdirectories inherit the bit itself. It changes group ownership only — the permission bits on the new file still come from the creating process.
solid answer
~50 sBy default a newly created file takes the creating process's primary group, which is why a shared tree ends up with a patchwork of groups. Setting the set-group-ID bit on the directory (`chmod g+s`, or a leading `2` as in `chmod 2775`) switches the kernel to the BSD rule: every file and subdirectory created inside inherits the **directory's** group, and every new subdirectory also inherits the set-group-ID bit, so the property propagates down the tree without a cron job fixing ownership. What it does **not** do is set permissions — the mode of each new file still comes from the process's file-creation mask, so if that mask strips group-write you get consistently group-owned files that colleagues still cannot edit. `ls` shows the bit as `s` in the group-execute slot. It also does not retroactively fix files that already exist.
code
bash · 3 linesmkdir -p /tmp/shared-project
chmod 2775 /tmp/shared-project
ls -ld /tmp/shared-projectgo deeper
Know that setting the setgid bit on a shared directory makes new files inherit that directory's group, and recognise the s in the group column of ls -l output.
Explain the default rule it replaces — a new file normally takes the creator's primary group — and that new subdirectories inherit the bit too, so the behaviour propagates down the tree.
Demonstrate that the bit alone does not produce a working shared tree: pair it with a creation mask that keeps group-write, a one-off recursive chgrp for existing content, and the sticky bit when members must not delete each other's files.
Own the collaboration model: decide whether shared group directories, per-service accounts, or a version-controlled workflow is the right answer, and account for how the choice behaves on network filesystems your fleet actually mounts.
## Default behaviour, and why it hurts here When a process creates a file, the kernel has to pick an owner and a group. The owner is the process's effective UID. The group, by default on Linux, is the process's **effective GID** — in practice the creator's primary group. So in a directory meant to be shared by the `devs` group, Alice's files land as `alice:alice` and Bob's as `bob:bob`. Neither can write the other's work through the `devs` group, because neither file is group-owned by `devs` at all. The directory's own group ownership is irrelevant to what happens inside it. ## What the set-group-ID bit changes Setting the set-group-ID bit on the **directory** switches the kernel to the alternative (BSD-derived) rule: 1. A file created in that directory takes **the directory's group**, not the creator's. 2. A **subdirectory** created in it takes the directory's group *and* inherits the set-group-ID bit itself. Point 2 is what makes the mechanism practical: you set the bit once at the top of the shared tree and every directory created beneath it keeps the behaviour. Without it you would be forever re-running `chgrp -R`. ``` mkdir /srv/project chgrp devs /srv/project chmod 2775 /srv/project # leading 2 = set-group-ID ls -ld /srv/project # drwxrwsr-x ... devs ... ``` The `s` sits in the **group-execute** slot. As with set-user-ID, a capital `S` means the bit is set while group-execute is not — on a directory that means the group cannot traverse it, which almost always defeats the purpose. ## What it deliberately does not change This is where interviews separate people who have configured a shared tree from people who have read about one. - **It does not set permissions.** Group ownership and group *permission* are different things. The mode of a new file is still derived from what the creating program requests, filtered through the process's file-creation mask. If that mask removes group-write, every new file is `-rw-r--r-- alice devs` — correctly group-owned and still unwritable by Bob. A working shared directory therefore needs both: the set-group-ID bit for ownership *and* a creation mask that leaves group-write intact, which usually means the participating accounts run with a mask permitting group write. - **It is not retroactive.** Existing files keep whatever group they already have; you fix them once with a recursive `chgrp`, and the bit handles everything created afterwards. - **It does not affect who may delete.** Deletion is still governed by write permission on the directory (plus the sticky bit, if present). A shared directory that is group-writable lets any group member remove any member's file unless you also set the sticky bit — `chmod 3770` gives you both. - **It says nothing about the process identity.** On a *binary*, the set-group-ID bit means something completely different: the process's effective GID becomes the file's group at exec, which is how programs that must write to terminal devices get access to the `tty` group. The same bit, two unrelated meanings depending on whether the target is a file or a directory. ## Choosing the mode For a private team tree, `2770` with the group set to the shared group is the usual shape: group members get full access, the world gets nothing, and inheritance is automatic. Add the sticky bit (`3770`) when members should not be able to delete each other's files. Use `2775` only when other users genuinely need to read the tree. ``` chgrp -R devs /srv/project find /srv/project -type d -exec chmod 2770 {} + find /srv/project -type f -exec chmod 660 {} + ``` ## Filesystem caveats The behaviour is implemented by the kernel's VFS layer and works on the usual Linux filesystems. Network filesystems can differ: with NFS the server enforces its own ownership rules, so verify inheritance against the actual export rather than assuming the local semantics carry over. And on filesystems where a default access-control list has been configured on the directory, that list is another inheritance mechanism operating alongside this bit — worth knowing exists, but it is a separate feature from the mode bit. The short version to say out loud: **set-group-ID on a directory fixes *who owns* new files, not *what may be done* to them.**
- The files are now group-owned by devs but colleagues still cannot edit them. What is missing?Group ownership without group permission. The setgid bit only decides which group owns a new file; the mode still comes from what the creating program asks for, filtered through the process's file-creation mask. If that mask clears group-write, every new file arrives read-only for the group. The accounts writing into the tree need a mask that leaves group-write in place.
- What does the same bit mean on an executable file rather than a directory?Something unrelated: at exec the process's effective GID becomes the file's group, exactly parallel to how set-user-ID changes the effective UID. That is how a utility permitted to write to other users' terminal devices gains membership of the tty group for the duration of the run. Directory inheritance and process-credential change happen to share one bit.
- Members keep deleting each other's files in the shared directory. How do you stop that?Add the sticky bit — `chmod 3770` gives you setgid plus restricted deletion. Deletion is governed by write permission on the directory, so anything group-writable lets any member unlink any entry. The sticky bit narrows rename and unlink to the file's owner, the directory's owner, and privileged processes, while leaving creation open.
saying these in an interview costs you the question
- Says the setgid bit grants group members write access.
- Expects it to fix the group on files that already exist.
- Confuses the directory meaning with the effective-GID change on a binary.
- Forgets the creation mask still strips group-write from new files.
- Thinks subdirectories need the bit set again by hand.