A setgid share that still is not writable, and a narrowly scoped sudo rule that is not narrow

Setgid on a directory only forces the group owner of new entries. It does not change the permission bits, which come from the creating process's umask. Alice's session has umask 0022, so files land 0644 and directories 0755 - the group gets r-x, so bob cannot overwrite.

Also, alice's running session predates her group addition: id in her shell will not show devs. Because the directory is setgid, new files still get group devs (setgid overrides the creator's primary group), which is why the symptom looks like a permissions problem and not a group-membership problem. Check both:

id alice                       # in her session - no devs yet (supplementary groups are fixed at login)
getent group devs
stat -c '%a %U:%G' /srv/build

Fix, in order:

1. Alice re-logs in, or runs newgrp devs for the current shell.
2. Set a per-user or per-directory umask of 0007 (/etc/profile.d/devshare.sh, or umask 0007 in the shared shell profile) so new files are 0660 and dirs 0770.
3. Repair what exists, without flattening the setgid bit:

find /srv/build -type d -exec chmod 2770 {} +
find /srv/build -type f -exec chmod 0660 {} +
chgrp -R devs /srv/build

Default ACLs (setfacl -R -m g:devs:rwX -m d:g:devs:rwX /srv/build) are the alternative when you cannot control every user's umask - they apply regardless of who creates the file.

Syntax is fine; behaviour is not what was asked. Two things to check:

1. sudoers is last-match, not first-match. The blanket ALL=(ALL) ALL for %wheel will still apply if it is evaluated later (or is unqualified in a way that wins for other commands). dave keeps full root access, and the narrow rule is decorative. Verify from outside dave's session:

sudo -l -U dave
sudo -l -U dave | grep -i 'systemctl restart builder'

If the output still says (ALL : ALL) ALL, either remove dave from wheel (the real fix, if he only needs this one command) or add a targeted ! revocation, realising that negations are fragile and hard to audit.

1. Exact-argument matching. sudo compares the command line as typed, so /usr/bin/systemctl restart builder.service or restart builder --no-block will not match and will fall through to the wheel rule - where they silently succeed with full root. That means the narrow rule is not the boundary you think it is. Test the variants, including systemctl restart builder; id.

Also: visudo -cf /etc/sudoers.d/50-dave, file mode 0440, and no dots in the filename (sudoers.d ignores names containing .). Then re-run sudo -l -U dave after every change - that command is the only evidence that matters.

It grants root to alice, via dave. dave can restart builder; the service executes /srv/build/builder.sh, which alice controls (mode 0660, group devs, and she is in devs). Whoever writes that script decides what runs as the unit's User= - and if the unit runs as root, that is direct root code execution with a restart as the trigger. Even a non-root unit is a lateral move onto every credential that unit can read.

Close it in this order:

1. Move the executed payload out of the shared writable tree: /usr/local/libexec/builder.sh, root:root 0755. Change ExecStart= to match. /srv/build becomes data only, never code.
2. Confirm ownership on the whole execution chain: systemctl cat builder (unit file and any drop-ins must be root-owned), find /usr/local/libexec -perm -o+w, and check the unit's User=, EnvironmentFile= and WorkingDirectory= for anything writable by devs.
3. Only then re-verify with sudo -l -U dave and by running the permitted command as dave.

The judgment point: a sudo rule is only as narrow as the command it launches. If the launched artifact is user-writable, NOPASSWD on one command is equivalent to ALL for whoever can edit that artifact - and they need no sudo at all.