explication sur chown (1) POSIX spec

La spécification POSIX pour l' chownutilitaire mentionne dans sa section sur la justification de la chown user:groupsyntaxe (anciennement chown user.group) (c'est moi qui souligne):

La méthode 4.3 BSD de spécification du propriétaire et du groupe a été incluse dans ce volume de POSIX.1-2008 car:

• Dans certains cas, la condition de fin souhaitée n'a pas pu être atteinte à l'aide des utilitaires chgrp et chown (qui n'ont modifié que l'ID utilisateur). (Si le propriétaire actuel n'est pas membre du groupe souhaité et que le propriétaire souhaité n'est pas membre du groupe actuel, la fonction chown () peut échouer à moins que le propriétaire et le groupe ne soient modifiés en même temps.)

Je pensais que la user:groupsyntaxe était une chose pratique. Maintenant, ce qui précède implique qu'il y a des choses que vous pouvez faire avec chown user:grouplesquelles vous ne pouvez paschgrp group; chown user

Maintenant, ce texte n'a plus de sens pour moi. Dans 4.3BSD, seul root pouvait changer le propriétaire d'un fichier, donc en tout cas il n'y a aucune restriction dans ce qu'il peut faire.

SysV et quelques autres systèmes permettent (ou permettaient) au propriétaire d'un fichier de changer l'utilisateur et le groupe d'un fichier en n'importe quoi, mais même dans ce système, le texte ci-dessus n'a pas de sens pour moi. OK, si on fait un chown someone-else the-file, on ne peut pas faire chgrp something-else the-fileaprès parce qu'on n'est plus le propriétaire du fichier, mais rien ne l'empêche de faire le chgrppremier (rester le propriétaire du fichier) et chownaprès, et ce n'est pas ce que le le texte ci-dessus dit exactement.

Je ne comprends pas ce que le propriétaire souhaité n'est pas membre du groupe actuel a à voir avec le problème.

Quelles sont donc les conditions pour lesquelles la fonction chown () pourrait échouer à moins que le propriétaire et le groupe ne soient modifiés en même temps , et sur quel système?

Le sous-système Microsoft Interix Unix (maintenant retiré) pour son noyau NT a traité un peu différemment les autorisations des utilisateurs et des groupes que certains autres:

Les informations sur les utilisateurs et les groupes sont stockées dans la base de données Security Access . Les utilisateurs et les groupes sont stockés dans la même base de données, mais les noms de groupe et d'utilisateur doivent être uniques; aucun groupe ne peut avoir le nom d'un utilisateur et vice versa. (Cette base de données remplace les fichiers /etc/passwdet /etc/groupssous UNIX.) Les utilisateurs et les groupes sont créés à l'aide de la méthodologie Windows appropriée (Gestionnaire des utilisateurs, Utilisateurs et ordinateurs Active Directory ou Utilisateurs et groupes locaux) ou à l'aide de la net usercommande Win32 . (Des exemples de scripts shell pour créer et supprimer des utilisateurs sont inclus dans le répertoire /usr/examples/admin.) Les utilisateurs peuvent appartenir à de nombreux groupes.

Voici quelques extraits manuels plus spécifiques:

Sous Windows, un utilisateur ou un groupe peut posséder un objet. Ceci est différent d'UNIX, dans lequel seul un utilisateur possède un objet.

Windows identifie tous les utilisateurs et groupes en interne à l'aide d'un identificateur de sécurité (SID) . Un algorithme de hachage génère des valeurs SID uniques; deux utilisateurs ou groupes n'auront pas le même SID.

Les utilisateurs et les groupes autorisés à accéder à un objet sont identifiés par leur SID. Tous les objets qui peuvent être sécurisés par Windows ont une liste de contrôle d'accès discrétionnaire (DACL), qui se compose d'entrées distinctes appelées entrées de contrôle d'accès (ACE). Un ACE comprend deux informations importantes: un SID d'utilisateur ou de groupe et une description de l'accès de l'utilisateur ou du groupe individuel à un objet.

CHGRP

... Modifiez l'ID de groupe du fichier ... l'utilisateur invoquant chgrp (1) doit appartenir au groupe spécifié et être le propriétaire du fichier, ou disposer des privilèges appropriés.

CHOWN

... Les opérandes propriétaire et groupe sont tous deux facultatifs; cependant, un doit être spécifié. Si l'opérande de groupe est spécifié, il doit être précédé de deux points (:).

Le propriétaire peut être spécifié par un ID utilisateur numérique ou un nom d'utilisateur. Si un nom d'utilisateur est également un ID utilisateur numérique, l'opérande est utilisé comme nom d'utilisateur. Le groupe peut être un ID de groupe numérique ou un nom de groupe. Si un nom de groupe est également un ID de groupe numérique, l'opérande est utilisé comme nom de groupe.

Pour des raisons de sécurité, la propriété d'un fichier ne peut être modifiée que par un processus disposant des privilèges appropriés.

Comme je l'ai lu, cela signifie que si votre compte d'utilisateur appartient à un groupe Windows avec des privilèges suffisants pour modifier les autorisations d'un fichier qui appartient à ce groupe, il est possible d'effectivement chgrpce fichier hors du contrôle de votre compte d'utilisateur. Cela équivaut à moins de contrôle que vous pourriez avoir avec chowndes user:groupparamètres explicites . Dans ce contexte sans possibilité de déclaration user: et :group vous n'auriez jamais pu obtenir les mêmes résultats qu'autrement.

Voici un lien vers un aperçu détaillé de la façon dont Interix interagit avec les listes de contrôle d'accès Windows en mettant l'accent sur la façon dont ces connaissances peuvent s'appliquer aux systèmes de fichiers Samba sur d'autres variantes Unix.

Voici un lien vers un document Solaris désormais obsolète décrivant le tunable rstchownqui ...

Indique si la sémantique POSIX pour l' chown(2)appel système est en vigueur ...

Apparemment, si le paramètre est réglé sur une valeur de 0...

... la désactivation de la sémantique POSIX ouvre la porte à diverses failles de sécurité. Cela ouvre également la possibilité à un utilisateur de changer la propriété d'un fichier à un autre utilisateur et de ne pas pouvoir récupérer le fichier sans l'intervention de l'utilisateur ou de l'administrateur système.

Une telle option n'invalide pas la conformité POSIX de Solaris . Le simple fait que ce soit une option le qualifie de conforme :

Bien que toutes les implémentations conformes à POSIX.1-2008 prennent en charge toutes les fonctionnalités décrites ci-dessous, il peut exister des procédures de configuration dépendant du système ou du système de fichiers qui peuvent supprimer ou modifier une ou toutes ces fonctionnalités. De telles configurations ne doivent pas être effectuées si une stricte conformité est requise.

Les constantes symboliques suivantes doivent être définies avec une valeur autre que -1. Si une constante est définie par la valeur zéro, les applications doivent utiliser les sysconf(), pathconf()ou fpathconf()fonctions, ou l' getconfutilité, pour déterminer quelles fonctions sont présentes sur le système à ce moment - là ou pour le chemin en question.

_POSIX_CHOWN_RESTRICTED

L'utilisation de chown()est limitée à un processus avec les privilèges appropriés et à la modification de l'ID de groupe d'un fichier uniquement à l'ID de groupe effectif du processus ou à l'un de ses ID de groupe supplémentaires.

La chown()fonction système - qui est l'appel système documenté effectué à la fois par les utilitaires shell chownet chgrp- est spécifiée pour échouer pour de nombreuses raisons. Parmi eux:

EACCES L'autorisation de recherche est refusée sur un composant du préfixe de chemin.

ELOOP Une boucle existe dans les liens symboliques rencontrés lors de la résolution de l'argument path.

EPERM L'ID utilisateur effectif ne correspond pas au propriétaire du fichier ou le processus appelant n'a pas les privilèges appropriés et _POSIX_CHOWN_RESTRICTED indique que ce privilège est requis.

Le comportement d'octroi de droits de modification d'autorisations à des utilisateurs non root n'a cependant jamais été unique à Solaris. Il y a une excellente couverture - bien que quelque peu datée - des autorisations de fichiers Unix dans ce post du forum dans lequel l'auteur déclare:

À l'origine, Unix autorisait un propriétaire de fichier à donner un fichier. Le propriétaire d'un fichier peut changer le propriétaire en quelqu'un d'autre. Il n'y avait aucun moyen pour un utilisateur non root d'annuler cette opération ... BSD [plus tard] supprimé chowndes utilisateurs non root ... [en partie parce que] ... il implémentait des quotas de disque qui pouvaient limiter l'espace disque l'utilisateur pourrait avoir dans un système de fichiers ... Les utilisateurs coquins pourraient donner des fichiers volumineux pour passer outre les quotas.

Aujourd'hui, il n'est pas facile de dire si un non-root peut chownun fichier. De nombreuses versions d'Unix autorisent les deux comportements ...

Un autre bon - et plus récent - message de liste de diffusion le cite et continue:

La valeur par défaut avec la plupart des OS est chownd'être limitée à root uniquement. Et il existe un consensus sur le fait que cela devrait rester ainsi pour des raisons de sécurité. Si un utilisateur non root change le propriétaire d'un fichier et que tout bit d'exécution est activé, les bits SUIDet SGIDdoivent être effacés. Cela peut ou non se produire avec root.

Je pense que ce dernier paragraphe le dit bien.

Cet article fait également référence CAP_CHOWNau contrôle de cette fonctionnalité sur Linux (qui ne devrait affecter que le POSIX_CHOWN_RESTRICTEDcomportement) . Il y a aussi la CAP_FOWNERcapacité, c'est un peu différent dans le comportement.

Et comme vous le signalez en 2003 :

Notez qu'au moins sur HPUX, vous pouvez changer le propriétaire de vos fichiers ( rootpar exemple) même si vous n'êtes pas un utilisateur privilégié ...

... qui dépendait d'un setprivgroupparamètre de configuration .

Dans tous les cas où un utilisateur non root peut manipuler les autorisations de fichier, il est concevable, comme cela est mentionné dans la justification citée dans votre question, qu'un utilisateur puisse chownun fichier que cet utilisateur possède afin qu'il appartienne à un autre utilisateur. Si la propriété du groupe du fichier et les chowngroupes de l'utilisateur ing ne s'alignent pas, l'utilisateur ne pourra plus modifier ce fichier.

Dans ce scénario, chown alors chgrp échouerait, car l'utilisateur n'aurait plus les autorisations pour modifier les autorisations de ce fichier, tandis que chown user:group- tant que le groupe serait parmi les siens - réussirait.

Il existe probablement de nombreuses autres situations de niche qui peuvent résulter de la même manière, qui peuvent inclure des répertoires de bits collants et / ou setgid , un système de fichiers et / ou des listes de contrôle d'accès spécifiques à l'implémentation. Ce fil est intéressant, par exemple. Les innombrables permutations sont bien au-delà de ma faible compréhension - c'est pourquoi cette réponse est wikied. Si vous lisez ceci, vous pensez que cela vaut la peine d'être amélioré et vous pensez savoir comment - veuillez le faire .

Il existe également une documentation complète sur les divers effets possibles des autorisations de fichiers, de la traversée de l'arborescence et des liens symboliques qui pourraient provoquer un échec similaire en ce qui concerne les applications -Recursives chownici:

À partir des en -têtes de section POSIX XRAT des troisième et quatrième domaines :

Généralement, les utilisateurs spécifiant l'option pour une traversée de hiérarchie de fichiers souhaitent opérer sur une seule hiérarchie physique, et donc les liens symboliques, qui peuvent référencer des fichiers en dehors de la hiérarchie, sont ignorés. Par exemple, le fichier propriétaire chown est une opération différente de la même commande avec l'option -R spécifiée. Dans cet exemple, le comportement de la commande chown owner fileest décrit ici, tandis que le comportement du chown -Rfichier propriétaire de la commande est décrit dans les troisième et quatrième domaines.

... Il y a un problème de sécurité avec le passage par défaut à une marche logique. Historiquement, le chown -Rfichier utilisateur de commande était sans danger pour le superutilisateur car les bits setuid et setgid étaient perdus lorsque la propriété du fichier était modifiée. Si la marche était logique, changer de propriétaire ne serait plus sûr car un utilisateur aurait pu insérer un lien symbolique pointant vers n'importe quel fichier de l'arborescence. Encore une fois, cela nécessiterait l'ajout d'une option aux commandes effectuant une traversée de la hiérarchie pour ne pas indirecter via les liens symboliques, et les scripts historiques faisant des promenades récursives deviendraient instantanément des problèmes de sécurité. Bien que cela soit principalement un problème pour les administrateurs système, il est préférable de ne pas avoir de valeurs par défaut différentes pour différentes classes d'utilisateurs.

...

Dans 4.3 BSD, chgrplors de la traversée de l'arbre, le groupe du lien symbolique a changé, pas la cible. Les liens symboliques dans 4.4 BSD n'avaient pas de propriétaire, de groupe, de mode ou d'autres attributs de fichier système UNIX standard.

Et à partir de la chgrppage POSIX proprement dite, il y a ceci qui pointe vers une possible -Raction ecursive incomplète , ou du moins vers ce qui était autrefois:

Les versions System V et BSD utilisent des codes d'état de sortie différents. Certaines implémentations utilisaient l'état de sortie comme un décompte du nombre d'erreurs survenues; cette pratique est irréalisable car elle peut déborder la plage de valeurs d'état de sortie valides. Les développeurs standard ont choisi de les masquer en spécifiant uniquement 0 et> 0 comme valeurs de sortie.

Hypothèse 1: les règles permettant de déterminer si un chownsuccès vérifie indépendamment les parties utilisateur et groupe cible, c'est-à-dire qu'elles sont de la forme user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters).

Hypothèse 2: chown(file, -1, -1)réussit.

Hypothèse 3: les règles pour déterminer si un chownsuccès ne dépend pas du groupe auquel appartient actuellement le fichier.

Corollaire: si chown(file, uid, gid)cela réussit, il en sera de même chown(file, -1, gid) && chown(file, uid, -1).

Je ne connais pas de variante Unix qui violerait l'une de ces hypothèses, elles semblent assez sûres.

Cette phrase ressemble à quelque chose que quelqu'un du comité a dit quand il était fatigué après des heures de débat sur le nombre d'options qui pourraient tenir sur la tête d'un psappel - ou que le secrétaire a mal transcrit - et que personne n'a attrapé pendant l'examen. Après tout, il existe d'autres bonnes raisons pour permettre à l'utilisateur et au groupe d'être modifiés automatiquement, y compris la raison de performance également citée dans la justification POSIX, ainsi que l'atomicité (ah, si seulement il y avait un seul appel pour changer la propriété et les autorisations ).

Un cas où l'hypothèse 3 pourrait être erronée concerne un système où un processus peut obtenir la capacité de changer les propriétaires de fichiers, mais uniquement s'ils ont une autorisation d'écriture sur le fichier. Bien que quelque peu réaliste, je ne connais aucun système où ce soit le cas. Ensuite, chgrpà un groupe à partir d'un processus qui ne s'exécutant ni en tant que root ni en tant qu'utilisateur propriétaire du fichier pourrait rendre le fichier hors limite pour une date ultérieure chown.

Pour un appel récursif, il existe des cas extrêmes où une passe entière de chgrpsuivie d'une passe entière de chownpeut échouer lorsqu'une seule passe réussit. Ce n'est pas un argument très convaincant, car il s'agit de répertoires que le propriétaire n'a pas l'autorisation de parcourir, et une application qui voulait se protéger contre tous ces cas devrait de toute façon manipuler les autorisations. Elle répond néanmoins techniquement à la condition de cette logique. Supposons que le processus en cours d'exécution ait un utilisateur efficace alice, un groupe efficace staffet la capacité de changer arbitrairement les propriétaires de fichiers (pas seulement pour les céder; plusieurs variantes Unix ont une telle capacité, bien qu'elle soit rarement accordée aux processus non root).

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied