Les utilisateurs non privilégiés (pas root) ne peuvent pas chown
à d'autres noms d'utilisateurs. Pour utiliser chown
un utilisateur doit avoir les privilèges de l'utilisateur cible. En d'autres termes, seuls les root
peut donner un fichier à un autre utilisateur.
Comme expliqué aquí (merci @slhck) :
Seuls les processus dont l'ID utilisateur effectif est égal à l'ID utilisateur du fichier ou qui disposent des privilèges appropriés peuvent modifier la propriété d'un fichier. Si _POSIX_CHOWN_RESTRICTED est en vigueur pour le chemin :
-
La modification de l'ID utilisateur est réservée aux processus disposant des privilèges appropriés.
-
La modification de l'ID de groupe est autorisée pour un processus dont l'ID d'utilisateur effectif est égal à l'ID d'utilisateur du fichier, mais sans les privilèges appropriés, si et seulement si owner est égal à l'ID d'utilisateur du fichier ou ( uid_t)-1 et group est égal soit à l'ID de groupe effectif du processus appelant, soit à l'un de ses ID de groupe supplémentaires.
Le raisonnement qui sous-tend cette démarche a été joliment expliqué par @Gilles en este Réponse Unix & Linux :
La raison de cette restriction est que le fait de donner un fichier à un autre à un autre utilisateur peut entraîner des conséquences fâcheuses dans des peu communes, mais néanmoins importantes. Par exemple :
- Si les quotas de disque sont activés sur un système, Alice peut créer un fichier inscriptible dans le monde entier dans un répertoire accessible uniquement par elle (donc pas de personne d'autre ne pourrait accéder à ce fichier inscriptible dans le répertoire), puis exécuter la commande chown pour que ce fichier appartienne à un autre utilisateur, Bill. Le fichier Le fichier serait alors comptabilisé dans le quota de disque de Bill, même si seule Alice peut utiliser le fichier. fichier.
- Si Alice donne un fichier à Bill, il n'y a aucune trace du fait que Bill n'a pas créé ce fichier. Cela peut poser un problème si le fichier contient des données illégales ou compromettantes.
- Certains programmes exigent que leur fichier d'entrée appartienne à un utilisateur particulier afin d'authentifier une requête (par exemple, le programme contient des instructions que le programme exécutera pour le compte de au nom de cet utilisateur). Il ne s'agit généralement pas d'une conception sûre, car même si Bill a créé un fichier contenant des instructions syntaxiques syntaxiquement correctes, il peut ne pas avoir eu l'intention de les exécuter à ce moment particulier. Néanmoins, le fait de permettre à Alice de créer un fichier au contenu fichier au contenu arbitraire et de le faire prendre en compte par Bill ne peut qu'aggraver les choses. les choses.