explication sur chown (1) POSIX spec

18

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?

Stéphane Chazelas
la source
1
@Robert, sur quel système ces règles s'appliqueraient-elles? Sur les systèmes que je connais, soit vous êtes root et vous pouvez faire ce que vous voulez, soit vous n'êtes pas utilisateur1 et vous ne pouvez rien faire. Si vous êtes utilisateur1, selon le système, vous ne pouvez pas changer le propriétaire de toute façon, ou, quand vous le pouvez, vous pouvez changer le groupe en ce que vous voulez, puis l'utilisateur en ce que vous voulez.
Stéphane Chazelas
Si j'ai dans un répertoire que je possède, un fichier appartenant à quelqu'un d'autre et un groupe dont je ne suis pas membre, mais que je peux lire en raison d'autres autorisations. Ensuite, il m'est possible de le copier pour me faire propriétaire, et il a un nouveau groupe (dont je suis membre). Par conséquent, il doit être aussi sauvegardé pour le système d'exploitation pour me permettre en tant que non-root chown me:my-group filesi le fichier se trouve dans un emplacement où j'ai un accès en lecture / écriture (non collant). Je ne pouvais pas chgrp d'abord en tant que non propriétaire. Je ne pouvais pas le montrer en premier car cela entraînerait un fichier que je ne pourrais pas créer: je possède un fichier avec un groupe dont je ne suis pas membre.
ctrl-alt-delor
@richard, non, ce ne serait pas aussi sûr . Ce fichier peut être lié à un autre répertoire auquel vous n'avez pas accès. Sur les systèmes où vous pouvez lier des fichiers que vous ne possédez pas (comme Linux par défaut), cela signifie que vous pouvez revendiquer la propriété de n'importe quel fichier en le liant à un répertoire auquel vous avez accès en écriture.
Stéphane Chazelas
J'ai trouvé ce texte, il explique aussi pourquoi je me trompe (ce n'est pas aussi sûr): «Si vous étiez autorisé à vous approprier le dossier, ce serait une faille de sécurité. Par exemple, l'utilisateur quelqu'un pourrait ouvrir le fichier, puis vérifier sa propriété et ses autorisations (en appelant fstat sur le descripteur de fichier ouvert), et conclure que seul un programme fonctionnant comme quelqu'un aurait pu produire ces données. Si vous pouviez vous approprier le fichier, vous pourriez alors changer son contenu contre les souhaits de quelqu'un. »- unix.stackexchange.com/questions/68439/…
ctrl-alt-delor

Réponses:

5

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.

mikeserv
la source
1
@StephaneChazelas - content d'avoir compris. "C'est" un gâchis de kinduva parce que je ne suis pas très bon avec l'ensemble des autorisations - en particulier lorsque les attributs SE sont impliqués. La connexion est lâche - links! = Ch {grp, own} mais je me suis dit que si les gars de POSIX auraient tant de mal à le préciser (il y a aussi un grand tableau sur la page), alors pour la même raison, un lien pourrait causer des problèmes alors deux actions -R pourraient aussi. Cela ne casserait rien si vous avez les deux pieds - utilisateur et groupe - comme vous le dites, mais si vous en avez déjà 1 hors tension. Quoi qu'il en soit, je l'ai wikied pour une raison. Pas vraiment mon fort. Pardon.
mikeserv
1
Bon point, je n'avais pas pensé à -R. On pourrait imaginer que vous pourriez perdre la recherche ou l'accès en lecture à un répertoire sur le chgrp, ce qui vous empêcherait de modifier les autorisations des fichiers, mais encore une fois avec les méthodes Unix traditionnelles pour gérer la propriété ou les autorisations, je ne vois pas comment pour y arriver. Un autre domaine qui mérite d'être étudié serait, je pense, les ACL NFSv4 sur les systèmes qui le supportent (Solaris, FreeBSD, SUSE ...)
Stéphane Chazelas
@ StéphaneChazelas - y a-t-il un aspect de votre question auquel ce post ne répond pas?
mikeserv
merci beaucoup pour cette recherche approfondie. Ce serait bien si vous pouviez ajouter un exemple avec le sous-système NT Unix où le texte POSIX s'applique. Je ne sais pas comment les primes fonctionnent avec les réponses du wiki communautaire. Je vais essayer.
Stéphane Chazelas
@ StéphaneChazelas - Je m'en fichais des points et je n'en ai jamais eu. J'espérais juste ne pas l'avoir foiré. Je ne suis pas sûr que je reçois la partie ce serait bien - voulez-vous dire NT Unix 4? Les documents officiels de Microsoft revendiquent la conformité POSIX au moins pour quand il s'agissait encore d'Interix, moi et ils déclarent un peu étrangement chgrp chown... peut ne pas se comporter comme vous vous attendez ...
mikeserv
1

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
Gilles 'SO- arrête d'être méchant'
la source
Notez que POSIX ne concerne pas seulement Unix. Il existe de nombreux systèmes d'exploitation non Unix qui ont un sous-système / API POSIX (par exemple Microsoft Windows NT). Je ne suis pas sûr que ces conditions soient suffisantes pour prétendre au corollaire. Le chgrpou chownpourrait avoir des effets secondaires qui affectent la capacité de faire l'autre. Par exemple, chownenlève la possibilité de chgrp, c'est un fait. chgrpefface le bit setuid / setgid, il peut effacer une forme d'ACL ou une autre forme de contexte de sécurité ...
Stéphane Chazelas
@ StéphaneChazelas Nous convenons que chownsuivi de chgrppourrait échouer, mais la question porte sur chgrpsuivi de chown. Hmmm, contexte de sécurité… peut-être dans un système avec un contrôle d'accès obligatoire, chgrppourrait tacher un fichier et le rendre illisible? Cela semble tiré par les cheveux.
Gilles 'SO- arrête d'être méchant'
Peut-être pas tiré par les cheveux. Je ne sais pas grand chose sur les ACL NFSv4 / WinNT mais je soupçonne qu'il y a quelque chose qui pourrait faire que ce genre de chose se produise (et / ou invalider votre 3ème hypothèse). Pourtant, ce texte est assez spécifique et celui qui l'a écrit aurait eu un exemple spécifique en tête. Peut-être qu'il a été écrit par des gens de Microsoft.
Stéphane Chazelas
re votre dernier montage. Avec chown -R bob: étudiants, alice perdrait toujours les autorisations de recherche dir, donc pour que cela fonctionne, chownil faudrait d'abord traiter la profondeur des fichiers et je ne connais aucune implémentation qui le fasse. C'est donc un cas presque valable où chgrp + chown échouerait là où chmod u: g ne pourrait pas, mais cela ne correspond pas vraiment au texte de la justification.
Stéphane Chazelas
La mauvaise transcription de la secrétaire non révisée et les chownthéories récursives des cas marginaux semblent être en conflit.
mikeserv