Comment empêcher chgrp d'effacer "bits setuid"?

Si vous voulez implémenter votre chgrp -R nobody /whatever tout en conservant le bit setuid, vous pouvez utiliser ces deux commands find

 find /whatever ! -type l -perm -04000 -exec chgrp nobody {} + \ -exec chmod u+s {} + find /whatever ! -type l ! -perm -04000 -exec chgrp nobody {} + 

L'option find ... -perm 04000 reprend les files avec le set bit set. La première command applique alors le chgrp puis un chmod pour rétablir le bit setuid qui a été désactivé. Le second applique chgrp à tous les files qui n'ont pas de bit setuid.

Dans tous les cas, vous ne voulez pas appeler chgrp ou chmod sur les liens symboliques car cela affecterait leurs cibles à la place, d'où le ! -type l ! -type l .

La suppression du bit setgid (au less sous Linux) setuid sur des non-directorys est effectuée par le kernel lors de l'appel système chown() effectué par chgrp , et non par chgrp lui-même. Donc, le seul moyen est de le restaurer ensuite.

Il efface également les capacités de security.

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 (en tant que root ):

 chown_preseve_sec :newgroup file1 file2... 

pour modifier le groupe en essayant de conserver les permissions.

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=- 

(c'est tout en supposant que rien ne gâche les files en même time).

La chgrp bits SUID et SGID sur chgrp (ou chown ) est parfaitement raisonnable. C'est une mesure de security afin de prévenir les problèmes de security. 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 security et de contrôle d'access c'est quelque chose de complètement différent, c'est-à-dire au lieu de courir avec le groupe efficace uvw le programme fonctionne maintenant avec le groupe xyz efficace.

Vous devez donc restaurer explicitement le bit SUID ou SGID lors du changement de propriété.

Addendum: Sur l'affirmation que chgrp (ou chown) devrait seulement effacer SGID (ou SUID, resp.)

En chgrp ou en chgrp les parameters de security d'un exécutable, vous devez effacer les attributes d'élévation de privilèges. La puissance d'Unix vient de la simplicité conceptuelle, et la security Unix est déjà assez délicate. À cette fin, retirer SUID et SGID de tout changement de propriétaire est simplement un filet de security – après tout, dans l'histoire d'Unix / Linux, il y a eu quelques vulnérabilités dues à des parameters SUID ou SGID erronés.

Donc, il n'y a pas de raison plus profonde pour laquelle Unix se comporte de cette façon, c'est juste une décision de design conservasortingce.

Comme d'habitude dans admin'ing il y a beaucoup de façons de faire.

La solution que je mets en place va comme ceci:

 cd /home/me getfacl -R /whatever > whatever-permissions.org 2> /dev/null # A) change lines starting with # group: root # to # group: whatineed sed 's/^# group: root/# group: whatineed/g' whatever-permissions.org > whatever-permissions.new # B) change lines with group::xy # to group::xwy # (where x, y mean: whatever was there before) sed 's/^group::\(.\).\(.\)/group::\1w\2/g' whatever-permissions.new > whatever-permissions.new cd / setfacl --restore /home/me/whatever-permissions.new