Qualche sistema simile a Unix attribuisce significato al bit SUID in una directory?
Domanda
Come dice il titolo, un sistema simile a Unix attribuisce un significato al bit SUID in una directory e, in tal caso, cosa significa?
Il bit SVTX (testo salvato o appiccicoso) ha un significato: non è possibile eliminare un file da questa directory se non è possibile scrivere sul file. È usato su / tmp, per esempio.
Il bit SGID (set GID) ha un significato: i file creati in questa directory devono appartenere al gruppo proprietario della directory (anche se tale assegnazione può essere successivamente modificata da una chiamata esplicita a chown (2)).
Che dire del bit SUID?
Soluzione
Come seguito della risposta di Node, posterò quanto segue dalla pagina man di FreeBSD per mount (8):
suiddir
A directory on the mounted file system will respond to
the SUID bit being set, by setting the owner of any new
files to be the same as the owner of the directory. New
directories will inherit the bit from their parents.
Execute bits are removed from the file, and it will not
be given to root.
This feature is designed for use on fileservers serving
PC users via ftp, SAMBA, or netatalk. It provides secu-
rity holes for shell users and as such should not be used
on shell machines, especially on home directories. This
option requires the SUIDDIR option in the kernel to work.
Only UFS file systems support this option. See chmod(2)
for more information.
E la sezione della pagina man chmod (2) che si riferisce al bit del suid:
4000 (the setuid bit). Executable files with this bit set will
run with effective uid set to the uid of the file owner.
Directories with this bit set will force all files and sub-
directories created in them to be owned by the directory
owner and not by the uid of the creating process, if the
underlying file system supports this feature: see chmod(2)
and the suiddir option to mount(8).
Si prega di essere consapevoli del fatto che si tratta di un rischio per la sicurezza e di sapere cosa si sta facendo quando lo si abilita, in FreeBSD ma credo che anche Linux richieda l'attivazione di un flag di montaggio speciale e cambierà il comportamento dei file in quella directory.
Altri suggerimenti
Copiato da qui :
Sulla maggior parte dei sistemi, se è impostato il bit set-group-ID di una directory, i file secondari appena creati ereditano lo stesso gruppo della directory e le sottodirectory appena create ereditano il bit set-group-ID della directory padre. Su alcuni sistemi, il bit set-user-ID di una directory ha un effetto simile sulla proprietà di nuovi file secondari e sui bit set-user-ID di nuove sottodirectory. Questi meccanismi consentono agli utenti di condividere i file più facilmente, riducendo la necessità di utilizzare chmod o chown per condividere nuovi file.
Questi meccanismi di convenienza si basano sui bit di directory set-user-ID e set-group-ID. Se comandi come chmod e mkdir cancellassero sistematicamente questi bit nelle directory, i meccanismi sarebbero meno convenienti e sarebbe più difficile condividere i file. Pertanto, un comando come chmod non influenza i bit set-user-ID o set-group-ID di una directory a meno che l'utente non li menzioni specificamente in una modalità simbolica o li imposta in una modalità numerica.
Se impostato su una directory, tutti i file e le directory creati all'interno di questa directory avranno lo stesso proprietario della directory SUID stessa, indipendentemente da chi abbia creato il file. Questa è una funzione che non viene utilizzata troppo spesso, ma può essere utile in alcuni casi. ( fonte )
Aggiornamento: ho appena provato questo su Linux 2.6.25.5-1.1-default # 1 SMP x86_64 GNU / Linux openSUSE 11.0 (X86-64).
mkdir tmp
chmod 4777 tmp
su othergroup
touch testfile
Non ha avuto effetto.
Il bit SUID afferma che, all'esecuzione di un file (quando eseguibile), il processo verrà eseguito con l'identità del proprietario di tale file, non dell'utente che lo ha eseguito.
Ci sono alcuni casi in cui un programma di utilità è 'suid root' per consentire l'escalation dei privilegi.
EDIT: domanda originale male interpretata (che si riferisce alle directory piuttosto che ai file) - lasciando la risposta inalterata per scopi educativi ;-)