Jaki jest cel katalogu setgid?

Wiem, jak działa Setgid, ale nie wiem, dlaczego został zaprojektowany. Czy istnieje przykład ilustrujący, jakie problemy rozwiązuje?

Chociaż plik / plik binarny setgid może nie być oczywiście użyteczny, zdecydowanie uważam, że bit setgid jest bardzo przydatny w katalogach. Zakładając, że jesteś częścią różnych grup roboczych, z których każda ma własne grupy uniksowe (zezwolenia). Z pewnością chciałbyś wtedy umieścić bit setgid w folderach projektu, upewniając się, że podczas tworzenia nowych plików stosowana jest właściwa własność grupy, a tym samym umożliwiając swoim kolegom z tej grupy projektowej dostęp do tych plików?

Głównym zastosowaniem jest zachowanie właściciela grupy drzewa plików:

[lockie@bubbles tmp]$ mkdir dir1 && touch dir1/file && mkdir dir1/dir
[lockie@bubbles tmp]$ mkdir dir2 && chgrp staff dir2 && chmod 2755 dir2 && touch dir2/file && mkdir dir2/dir
[lockie@bubbles tmp]$ ls -al dir1
total 32
drwxrwxr-x   3 lockie  lockie   4096 Dec 13 19:32 .
drwxrwxrwt 125 root root 20480 Dec 13 19:32 ..
drwxrwxr-x   2 lockie  lockie   4096 Dec 13 19:32 dir
-rw-rw-r--   1 lockie  lockie      0 Dec 13 19:32 file
[lockie@bubbles tmp]$ ls -al dir2
total 32
drwxr-sr-x   3 lockie  staff  4096 Dec 13 19:32 .
drwxrwxrwt 125 root root  20480 Dec 13 19:32 ..
drwxrwsr-x   2 lockie  staff  4096 Dec 13 19:32 dir  < note new dir is g+s, owned by "staff" group, so the setgid behaviour acts recursively
-rw-rw-r--   1 lockie  staff     0 Dec 13 19:32 file < note new file is owned by "staff" group
[lockie@bubbles tmp]$

Jest to zwykle przydatne w środowiskach, w których różni użytkownicy będą tworzyć / edytować pliki / katalogi w katalogu: Gdy wszystkie pliki / katalogi współużytkują tę samą grupę, wszyscy użytkownicy mogą edytować / zmieniać pliki / katalogi (jeśli pozwalają na to uprawnienia): Pozwala to uniknąć sytuacji na przykład „xyz jest właścicielem pliku abc, więc nie mogę go edytować”.

Alternatywą dla używania setgid w ten sposób jest opcja montowania systemu plików grpid .

Z wierzchowca człowieka:

grpid lub bsdgroups / nogrpid lub sysvgroups

Te opcje określają, jaki identyfikator grupy otrzymuje nowo utworzony plik. Po ustawieniu grpid pobiera identyfikator grupy katalogu, w którym został utworzony; w przeciwnym razie (domyślnie) pobiera fsgid bieżącego procesu, chyba że katalog ma ustawiony bit setgid, w którym to przypadku pobiera gid z katalogu nadrzędnego, a także otrzymuje bit setgid, jeśli jest to sam katalog.

Po włączeniu pliki / katalogi utworzone w zamontowanym systemie plików grpid również dziedziczą grupę katalogu nadrzędnego:

[lockie@bubbles ~]$ mount | grep /home
/dev/mapper/VolGroup00-home on /home type ext3 (rw,grpid)
[lockie@bubbles ~]$ mkdir dir3 && touch dir3/file && mkdir dir3/dir
[lockie@bubbles ~]$ ls -al dir3
total 12
drwxrwxr-x  3 lockie users 4096 Dec 13 19:37 .
drwxrwxr-x 12 lockie users 4096 Dec 13 19:37 ..
drwxrwxr-x  2 lockie users 4096 Dec 13 19:37 dir < inherited "users" group from parent dir
-rw-rw-r--  1 lockie users    0 Dec 13 19:37 file  < inherited "users" group from parent dir
[lockie@bubbles ~]$

Odkryłem, że użycie opcji grpid odpowiednio zmniejsza ryzyko błędu ludzkiego (ponieważ system plików działa, niezależnie od uprawnień dir).