Rappelez-vous que les bits setuid et setgid ont été inventés dans un but complètement différent :faire en sorte qu'un exécutable s'exécute avec l'uid ou le gid de son propriétaire, plutôt que l'uid ou le gid de l'utilisateur exécutant le fichier. Toute autre utilisation n'est qu'une fonctionnalité supplémentaire.
Ces bits n'ont aucune fonction sur les fichiers ordinaires qui ne sont pas exécutables. (Et aussi des scripts shell sur certaines distributions, en raison de problèmes de sécurité.) À l'origine, ils n'avaient pas non plus de fonction pour les répertoires. De toute évidence, quelqu'un a décidé qu'il serait cool de prendre le setgid inutilisé sur les répertoires et de l'utiliser pour renforcer la cohérence de la propriété du groupe. Après tout, si vous jouez avec la propriété de groupe, c'est parce que plus d'une personne travaille avec le fichier, et il est probablement logique que tous les fichiers d'un répertoire donné appartiennent au même groupe, peu importe qui les a créés. Les tracas dus à quelqu'un qui oublie d'exécuter newgrp sont éliminés.
Alors, pourquoi ne pas implémenter la même fonctionnalité pour setuid et le fichier uid ? Eh bien, uid est beaucoup plus basique que gid. Si vous implémentez cela, souvent un fichier n'appartiendra pas à l'utilisateur qui l'a créé ! Vraisemblablement, l'utilisateur peut toujours modifier le fichier (en supposant que umask est quelque chose de sensé), mais il ne peut pas modifier les bits d'autorisation. Difficile d'en voir l'utilité.
Je crois que la réponse à cette question porte sur les problèmes de sécurité du "distribution de fichiers" qui ont fait que la plupart des systèmes d'exploitation modernes de type Unix n'autorisent pas le "distribution de fichiers". La "distribution de fichiers" se produit lorsqu'un utilisateur non superutilisateur change la propriété d'un fichier à quelqu'un d'autre que cet utilisateur. Cette capacité offre de nombreuses possibilités de méfaits.
Étant donné que les cadeaux de fichiers ne sont pas autorisés, setuid sur les répertoires, qui rempliraient la même fonction sous une autre forme, n'est pas autorisé ou ignoré s'il est défini.
Pour changer le comportement, vous devrez modifier les bibliothèques et les utilitaires du système d'exploitation.
Voici un très bon cas d'utilisation pour l'implémenter :
Disons que vous avez un serveur multi-sites avec 3 sites sécurisés. Vous avez 3 groupes créés, un pour chacun des différents mainteneurs de sites. Tous les fichiers de tous les sites doivent appartenir à l'utilisateur apache afin qu'apache puisse les lire et y écrire (drupal/wordpress, etc.).
Si le setuid fonctionnait comme le bit setgid pour les autorisations de répertoires, cela ressemblerait à ceci :
/var/www/sitea - apache:groupa rwS rwS ---
/var/www/siteb - apache:groupb rwS rwS ---
/var/www/sitec - apache:groupc rwS rwS ---
De cette façon, chaque groupe de mainteneurs avait accès pour voir et toucher uniquement leur contenu, mais l'utilisateur du serveur Web apache pouvait servir tout le contenu et les utilisateurs n'avaient pas besoin de s'inquiéter de changer la propriété des fichiers téléchargés.
Un autre cas d'utilisation concerne les téléchargements anonymes ftp/http ou même sftp/ssh. Le groupe et le GID sur le répertoire de téléchargement seraient root, tout comme le propriétaire et l'UID. Les autres autorisations seraient -wx . Cela permettrait à tout le monde d'accéder en ÉCRITURE au répertoire de téléchargement, mais ils ne pourraient rien lire une fois qu'il a été téléchargé et la racine serait propriétaire de tous les fichiers nouvellement créés.
Il existe donc deux cas d'utilisation parfaitement valides et valides pour activer la fonctionnalité UID sur les répertoires afin qu'elle corresponde au bit GID.
Steven Mercurio