Perché setuid viene ignorato nelle directory?

Sui sistemi Linux, puoi riuscire chmod u+s $some_directory, ma invece di forzare la proprietà di nuove sottodirectory e file di essere il proprietario della directory di contenimento (e impostare anche le sottodirectory u+s) come ci si potrebbe aspettare, il sistema ignora semplicemente il bit setuid. Le sottodirectory e i file continuano a ereditare gli UID dei loro processi di creazione e le sottodirectory non sono impostate per impostazione predefinita.

Perché setuid viene ignorato nelle directory e come posso far sì che il sistema lo riconosca?

Ricordiamo che i bit setuid e setgid sono stati inventati per uno scopo completamente diverso: far funzionare un eseguibile con l'UID o GID del suo proprietario, piuttosto che l'UID o GID dell'utente che esegue il file. Qualsiasi altro utilizzo è solo una funzionalità aggiuntiva.

Questi bit non hanno alcuna funzione su file ordinari che non sono eseguibili. (E anche script di shell su alcune distro, a causa di problemi di sicurezza.) Inizialmente, non avevano alcuna funzione per le directory. Ovviamente qualcuno ha deciso che sarebbe bello prendere il setgid inutilizzato nelle directory e usarlo per imporre la coerenza della proprietà del gruppo. Dopotutto, se stai giocando con la proprietà del gruppo, è perché più di una persona sta lavorando con il file, e probabilmente ha senso che tutti i file in una determinata directory appartengano allo stesso gruppo, indipendentemente da chi li ha creati. Le preoccupazioni dovute a qualcuno che si dimentica di eseguire newgrp vengono eliminate.

Quindi, perché non implementare la stessa funzione per setuid e il file uid? Bene, uid è molto più semplice di gid. Se lo implementate, spesso un file non appartiene all'utente che lo ha creato! Presumibilmente l'utente può comunque modificare il file (supponendo che umask sia qualcosa di sano), ma non può cambiare i bit di autorizzazione. Difficile vederne l'utilità.

Credo che la risposta a questa domanda riguardi i problemi di sicurezza del "file giveaway" che hanno portato la maggior parte dei moderni sistemi operativi simili a Unix a non consentire il "giveaway file". Il "file giveaway" è quando un utente non superutente cambia la proprietà di un file in una persona diversa da quell'utente. Questa capacità offre molte opportunità di malizia.

Poiché non sono consentiti omaggi di file, setuid su directory, che eseguono la stessa funzione in un altro formato, non è consentito o ignorato se impostato.

Per quanto riguarda la modifica del comportamento, è necessario modificare le librerie e le utilità del sistema operativo.

Un ottimo caso d'uso per implementarlo è questo:

Supponiamo che tu abbia un server multi-sito con 3 siti sicuri. Hai creato 3 gruppi, uno per ciascuno dei diversi manutentori dei siti. Tutti i file in tutti i siti devono essere di proprietà dell'utente apache in modo che apache possa leggere e scrivere su di essi (drupal / wordpress, ecc.).

Se il setuid ma funzionasse come il bit setgid per le autorizzazioni delle directory sarebbe simile a questo:

/var/www/sitea - apache:groupa  rwS rwS ---
/var/www/siteb - apache:groupb  rwS rwS ---
/var/www/sitec - apache:groupc  rwS rwS ---

In questo modo ogni gruppo di manutentori ha avuto accesso a vedere e toccare solo il loro contenuto, ma l'apache dell'utente del server web poteva servire tutto il contenuto e non è necessario che gli utenti si preoccupino di cambiare la proprietà dei file caricati.

Un altro caso d'uso è per i caricamenti anonimi ftp / http o anche sftp / ssh. Il gruppo e il GID nella directory di caricamento sarebbero root, così come il proprietario e l'UID. Le altre autorizzazioni sarebbero -wx. Ciò consentirebbe a chiunque di SCRIVERE l'accesso alla directory di caricamento, ma non potrebbe leggere nulla una volta che è stato caricato e root possederebbe tutti i file appena creati.

Quindi ci sono due casi d'uso perfettamente validi e validi per abilitare la funzionalità UID nelle directory in modo che corrisponda al bit GID.

Steven Mercurio

Un po 'tardi alla festa, ma nel caso in cui i futuri lettori si imbattano in questo;) Come affermato da altri, su un file system OS-X standard il setUID per le directory viene ignorato - e non sembra esserci un modo semplice per aggirare questo ( mount -o.... o cosa no). Come spesso accade, la pagina man in realtà non è conforme al comportamento OS-X che afferma letteralmente:

4000 (il set-user-ID-on-esecuzione bit) [...] Le directory con il set-user-id bit set imporranno che tutti i file e le sottodirectory in essi creati siano di proprietà del proprietario della directory e non di l'uid del processo di creazione [...]

ma elenca anche la possibilità di ottenere lo stesso effetto senza rinunciare alla proprietà originale. Linux usa '[g /] setfacls' per effetti simili (sono autorizzazioni non realmente visibili a prima vista, quindi a volte può essere un fastidio).

Per quanto riguarda il "come posso ottenere effetti simili", leggi l'intera pagina man e giocherella con:

chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]

puoi controllare tramite

ls -le

se tutto sembra a posto. Altre opzioni includono l'inserimento di regole in posizioni specifiche, la rimozione o la sostituzione di regole specifiche. Le due opzioni degne di nota qui sono " file_inherite directory_inherit" che consentono di allegare le regole a una nuova directory / file.

Non mi piace molto usare setUID, ma setGID è molto utile sui server di file in cui la semplice impostazione del gruppo 'principale' non funziona o i client hanno maschere di file che non consentono la scrittura di gruppo. Ciò sarebbe risolto da:

chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup

Bene, dovrebbe rispettare lo standard. Riesco a pensare a diversi scenari con sftp-only che mi risparmierebbe molti problemi, sia con acl che con acl-mask-set che sshd fa, e il reset che devo fare per quella maschera.

La sicurezza di default è abbastanza utile, ma se non la fai diventare un'opzione, stai solo creando un winghtmare.

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

Ad ogni modo, è come procede ora Linux, quindi basta usare acl per aggirare quelli.

Secondo http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories il bit setuid viene ignorato per le directory su entrambi i sistemi UNIX e Linux. Tuttavia, è possibile farlo funzionare come previsto su FreeBSD.