Se vuoi implementare il tuo chgrp -R nobody /whatever mantenendo il bit setuid puoi usare questi due find comandi
find /whatever ! -type l -perm -04000 -exec chgrp nobody {} + \
-exec chmod u+s {} +
find /whatever ! -type l ! -perm -04000 -exec chgrp nobody {} +
Il find ... -perm 04000 l'opzione preleva i file con il bit setuid impostato. Il primo comando applica quindi il chgrp e poi un chmod per ripristinare il bit setuid che è stato eliminato. Il secondo applica chgrp a tutti i file che non hanno un bit setuid.
In ogni caso, non vuoi chiamare chgrp o chmod sui collegamenti simbolici in quanto ciò influenzerebbe invece i loro obiettivi, da qui il ! -type l .
Cancellazione dei bit SUID e SGID su chgrp (o chown ) è perfettamente ragionevole. È una misura di sicurezza per prevenire problemi di sicurezza. Per SGID (su eseguibili, presumo) significa eseguire questo programma con il gruppo effettivo del proprietario del gruppo .
Se cambi il proprietario del gruppo, in termini di sicurezza e controllo degli accessi questo è qualcosa di completamente diverso, cioè invece di funzionare con il gruppo effettivo uvw il programma ora viene eseguito con il gruppo effettivo xyz .
Quindi devi ripristinare esplicitamente il bit SUID o SGID al cambio di proprietà.
Addendum:sull'affermazione che chgrp (o chown) dovrebbe cancellare solo SGID (o SUID, rispettivamente)
Da chown ing o chgrp ti chiede di modificare l'impostazione di sicurezza per un eseguibile e questo è un motivo sufficiente per cancellare qualsiasi attributo di elevazione dei privilegi. La potenza di Unix deriva dalla semplicità concettuale, e la sicurezza di Unix è già piuttosto complicata. A tal fine, la rimozione di SUID e SGID a qualsiasi cambio di proprietà è semplicemente una rete di sicurezza - dopotutto, nella storia di Unix/Linux ci sono state parecchie vulnerabilità dovute a impostazioni errate di SUID o SGID.
Quindi non c'è una ragione più profonda per cui Unix si comporta in questo modo, è solo una decisione progettuale conservativa.
La cancellazione del setuid , setgid bit (almeno su Linux) su non-directory viene eseguito dal kernel su chown() chiamata di sistema eseguita da chgrp , non da chgrp si. Quindi l'unico modo è ripristinarlo in seguito.
Cancella anche le funzionalità di sicurezza.
Quindi, su GNU Linux:
chown_preserve_sec() (
newowner=${1?}; shift
for file do
perms=$(stat -Lc %a -- "$file") || continue
cap=$(getfattr -m '^security\.capability$' --dump -- "$file") || continue
chown -- "$newowner" "$file" || continue
[ -z "$cap" ] || printf '%s\n' "$cap" | setfattr --restore=-
chmod -- "$perms" "$file"
done
)
Ed esegui (come root ):
chown_preseve_sec :newgroup file1 file2...
per modificare il gruppo durante il tentativo di conservare i permessi.
Ricorsivamente, potresti fare:
# save permissions (and ACLs). Remove the "# owner" and "# group" lines
# to prevent them being restored!
perms=$(getfacl -RPn . | grep -vE '^# (owner|group): ')
# save capabilities
cap=$(getfattr -Rhm '^security\.capability$' --dump .)
chgrp -RP nobody .
# restore permissions, ACLs and capabilities
printf '%s\n' "$perms" | setfacl --restore=-
[ -z "$cap" ] || printf '%s\n' "$cap" | setfattr -h --restore=-
(questo è tutto presupponendo che nulla stia incasinando i file allo stesso tempo).