chown supprime le bit setuid: bug ou fonctionnalité?

14

Étapes à reproduire:

germar@host:~$ cd /tmp/
germar@host:/tmp$ touch test && chmod u+s test && ls -la test
-rwSr--r-- 1 germar germar 0 Nov  2 20:11 test
germar@host:/tmp$ chown germar:germar test && ls -la test
-rw-r--r-- 1 germar germar 0 Nov  2 20:11 test

Testé avec Debian squeeze et Ubuntu 12.04

permissions users chown Germar
la source
Est-ce que sur Fedora 17 aussi.
BenjiWiebe
1
fonction
mikeserv

Réponses:

17

Pas un bug selon la documentation chown:

$ info coreutils 'chown invocation'

   The `chown' command sometimes clears the set-user-ID or set-group-ID
permission bits.  This behavior depends on the policy and functionality
of the underlying `chown' system call, which may make system-dependent
file mode modifications outside the control of the `chown' command.
For example, the `chown' command might not affect those bits when
invoked by a user with appropriate privileges, or when the bits signify
some function other than executable permission (e.g., mandatory
locking).  When in doubt, check the underlying system behavior.
jlliagre
la source
Merci jlliagre. Je ne le savais pas info coreutilsavant. Je n'ai lu que la page de manuel et cherché sur le Web.
Germar
12

C'est par conception, et c'est un comportement standard. Citant la norme POSIX :

À moins que chown ne soit invoqué par un processus avec les privilèges appropriés, les bits set-user-ID et set-group-ID d'un fichier normal doivent être effacés une fois la tâche terminée avec succès; les bits set-user-ID et set-group-ID d'autres types de fichiers peuvent être effacés.

(s est setuid (ou setgid dans la colonne groupe), pas collant, au fait.)

Ce comportement suit celui de l' appel système sous - jacent (sauf que sur certains systèmes, les bits setxid ne sont effacés que pour les fichiers exécutables).

La raison de la suppression du bit setuid est que le changement de propriétaire change également l'utilisateur qui sera l'ID utilisateur effectif du processus. En particulier, sur les systèmes où un utilisateur peut donner un fichier, cp /bin/sh foo; chmod u+s foo; chown joe foocréerait un exécutable setuid appartenant à Joe, un trou de sécurité géant.

Gilles 'SO- arrête d'être méchant'
la source
Votez pour le nitpick! SUID / SGID ne sont pas le bit "collant"!
Jim Dennis
Grand point sur les implications de sécurité de la préservation de SUID / SGID. J'ai été gêné par le comportement jusqu'à ce que je lise cette phrase. J'ajouterais, cependant, que je n'ai jamais vu chown ne pas effacer les bits, même lors de l'exécution en tant que root. Je suis curieux de savoir ce que "des privilèges appropriés" impliqueraient.
vastlysuperiorman
1
@vastlysuperiorman Sur une plate-forme Unix classique, «privilèges appropriés» signifie l'ID utilisateur 0. Mais POSIX permet aux systèmes de définir leurs propres politiques de sécurité. Par exemple, pour de nombreuses opérations sous Linux, les «privilèges appropriés» sont implémentés en tant que capacité (que seul root obtient par défaut). Dans ce cas particulier, supprime les bits setxid sur chown indépendamment des privilèges, comme la plupart sinon toutes les variantes Unix. Mais une couche POSIX sur Windows peut fonctionner différemment.
Gilles 'SO- arrête d'être méchant'