The account that was almost on the team — cheat sheet
users-permissions
# identity
id [user] # uid, primary gid, supplementary groups
id -nG user # just the group names
getent passwd user # through NSS, so LDAP/SSSD are included
getent group devops # who is in the group
groups user # the same, shorter
newgrp devops # a new shell with the group, without logging out
# membership
usermod -aG devops user # ADD a supplementary group ← the safe one
usermod -G devops user # REPLACE the whole list ← the destructive one
usermod -g devops user # change the primary group
gpasswd -d user developers # remove one membership
useradd -m -s /bin/bash user # with a home and a real shell
# permissions
ls -ld /srv/project # the directory itself, not its contents
stat -c '%A %a %U:%G' PATH # symbolic mode, octal mode, owner:group
chmod 2770 DIR # rwxrws--- : group may create, files inherit the group
chmod g+s DIR # setgid, symbolically
chmod 1777 DIR # sticky: only the owner deletes their own (like /tmp)
chgrp -R devops DIR # fix the files that already exist
chmod -R g+w DIR # …and their modes
find DIR \! -group devops # what setgid did not catch
# umask
umask # the mask in this shell
su - user -c umask # the mask a LOGIN shell gets ← what matters
umask 002 # files 664, dirs 775 (collaborative)
umask 022 # files 644, dirs 755 (default; no group write)
grep -r umask /etc/profile /etc/profile.d/ /etc/login.defs ~/.bash_profile ~/.bashrc
# sudo
sudo -l -U user # what sudo would allow that user
sudo -l -U user /usr/bin/cmd # one exact command: exit 0 if permitted
visudo -f /etc/sudoers.d/devops # edit a drop-in, checked on save
visudo -c # verify sudoers and every drop-in
sudo ls -l /etc/sudoers.d/ # must be 0440 root:root, no dots in the name (the dir itself is 0750)