Wenn Sie Ihren chgrp -R nobody /whatever implementieren möchten Unter Beibehaltung des Setuid-Bits können Sie diese beiden find verwenden Befehle
find /whatever ! -type l -perm -04000 -exec chgrp nobody {} + \
-exec chmod u+s {} +
find /whatever ! -type l ! -perm -04000 -exec chgrp nobody {} +
Die find ... -perm 04000 Option nimmt Dateien mit gesetztem setuid-Bit auf. Der erste Befehl wendet dann die chgrp an und dann ein chmod um das abgeschlagene setuid-Bit wiederherzustellen. Der zweite gilt chgrp auf alle Dateien, die kein setuid-Bit haben.
Auf keinen Fall möchten Sie chgrp anrufen oder chmod auf Symlinks, da dies stattdessen ihre Ziele beeinflussen würde, daher der ! -type l .
Löschen von SUID- und SGID-Bits auf chgrp (oder chown ) ist vollkommen in Ordnung. Dies ist eine Sicherheitsmaßnahme, um Sicherheitsproblemen vorzubeugen. Für SGID (bei ausführbaren Dateien, nehme ich an) bedeutet dieses Programm mit der effektiven Gruppe des Gruppenbesitzers ausführen .
Wenn Sie den Gruppenbesitzer ändern, dann ist das in Bezug auf Sicherheit und Zugriffskontrolle etwas ganz anderes, d.h. statt mit der effektiven Gruppe uvw zu laufen das Programm läuft jetzt mit der effektiven Gruppe xyz .
Daher müssen Sie das SUID- oder SGID-Bit bei einem Eigentümerwechsel explizit wiederherstellen.
Nachtrag:Zur Behauptung, dass chgrp (oder chown) nur SGID (bzw. SUID) löschen soll
Mit chown oder chgrp Wenn Sie die Sicherheitseinstellung für eine ausführbare Datei ändern, ist dies ein ausreichender Grund, alle berechtigungserhöhenden Attribute zu löschen. Die Stärke von Unix liegt in der konzeptionellen Einfachheit, und die Unix-Sicherheit ist bereits ziemlich schwierig. Zu diesem Zweck ist das Entfernen von SUID und SGID bei jedem Eigentümerwechsel nur ein Sicherheitsnetz - schließlich gab es in der Geschichte von Unix/Linux einige Schwachstellen aufgrund fehlgeleiteter SUID- oder SGID-Einstellungen.
Es gibt also keinen tieferen Grund, warum Unix sich so verhält, es ist nur eine konservative Designentscheidung.
Die Räumung der setuid , setgid Bit (zumindest unter Linux) auf Nicht-Verzeichnissen wird vom Kernel auf chown() ausgeführt Systemaufruf erfolgt durch chgrp , nicht von chgrp selbst. Die einzige Möglichkeit besteht also darin, es danach wiederherzustellen.
Es löscht auch die Sicherheitsfunktionen.
Also unter 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
)
Und ausführen (als root ):
chown_preseve_sec :newgroup file1 file2...
die Gruppe zu ändern, während versucht wird, die Berechtigungen beizubehalten.
Rekursiv könnten Sie Folgendes tun:
# 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=-
(Das ist alles vorausgesetzt, dass nichts gleichzeitig die Dateien durcheinander bringt).