Si vous souhaitez implémenter votre chgrp -R nobody /whatever tout en conservant le bit setuid vous pouvez utiliser ces deux find commandes
find /whatever ! -type l -perm -04000 -exec chgrp nobody {} + \
-exec chmod u+s {} +
find /whatever ! -type l ! -perm -04000 -exec chgrp nobody {} +
Le find ... -perm 04000 L'option récupère les fichiers avec le bit setuid défini. La première commande applique alors le chgrp puis un chmod pour rétablir le bit setuid qui a été renversé. La seconde applique chgrp à tous les fichiers qui n'ont pas de bit setuid.
Dans tous les cas, vous ne voulez pas appeler le chgrp ou chmod sur les liens symboliques car cela affecterait plutôt leurs cibles, d'où le ! -type l .
Effacement des bits SUID et SGID sur chgrp (ou chown ) est parfaitement raisonnable. C'est une mesure de sécurité afin d'éviter les problèmes de sécurité. Pour SGID (sur les exécutables, je présume) signifie exécuter ce programme avec le groupe effectif du propriétaire du groupe .
Si vous changez le propriétaire du groupe, alors en termes de sécurité et de contrôle d'accès, c'est quelque chose de complètement différent, c'est-à-dire au lieu de fonctionner avec le groupe effectif uvw le programme s'exécute maintenant avec le groupe effectif xyz .
Ainsi, vous devez restaurer explicitement le bit SUID ou SGID lors du changement de propriétaire.
Addendum :Sur l'affirmation selon laquelle chgrp (ou chown) ne devrait effacer que SGID (ou SUID, resp.)
Par chown ou chgrp vous modifiez le paramètre de sécurité d'un exécutable, et c'est une raison suffisante pour effacer tous les attributs d'élévation de privilèges. La puissance d'Unix vient de la simplicité conceptuelle, et la sécurité Unix est déjà assez délicate. À cette fin, la suppression de SUID et SGID lors de tout changement de propriétaire est simplement un filet de sécurité - après tout, dans l'histoire d'Unix/Linux, il y avait pas mal de vulnérabilités dues à des paramètres SUID ou SGID erronés.
Il n'y a donc pas de raison plus profonde pour laquelle Unix se comporte de cette façon, c'est juste une décision de conception prudente.
Le dégagement du setuid , setgid bit (au moins sous Linux) sur les non-répertoires est effectué par le noyau sur le chown() appel système effectué par chgrp , pas par chgrp lui-même. Le seul moyen est donc de le restaurer par la suite.
Il efface également les fonctionnalités de sécurité.
Donc, sur 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
)
Et exécutez (comme root ):
chown_preseve_sec :newgroup file1 file2...
pour changer de groupe tout en essayant de conserver les autorisations.
Récursivement, vous pourriez faire :
# 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=-
(tout cela en supposant que rien ne gâche les fichiers en même temps).