Je pense que je comprends plutôt comment fonctionnent les autorisations de fichiers sous Linux. Cependant, je ne comprends pas vraiment pourquoi ils sont divisés en trois niveaux et non en deux.
J'aimerais que les problèmes suivants soient résolus:
- Est-ce une conception délibérée ou un patch? C'est-à-dire - les autorisations du propriétaire / groupe ont-elles été conçues et créées avec une justification ou sont-elles venues l'une après l'autre pour répondre à un besoin?
- Existe-t-il un scénario dans lequel le schéma utilisateur / groupe / autre est utile mais un schéma groupe / autre ne suffit pas?
Les réponses à la première doivent citer des manuels ou des forums de discussion officiels.
Les cas d'utilisation que j'ai envisagés sont:
- fichiers privés - très facilement accessibles en créant un groupe par utilisateur, ce qui est souvent fait comme dans de nombreux systèmes.
- autoriser uniquement le propriétaire (par exemple, le service système) à écrire dans un fichier, autoriser uniquement un certain groupe à lire et refuser tout autre accès - le problème avec cet exemple est qu'une fois que le groupe doit disposer d'un accès en écriture, l'utilisateur / group / other échoue avec cela. La réponse pour les deux utilise des listes de contrôle d'accès et ne justifie pas, à mon humble avis, l'existence d'autorisations de propriétaire.
NB J'ai raffiné cette question après l'avoir fermée dans superuser.com .
EDIT corrigé "mais un schéma de groupe / propriétaire ne suffira pas" à "... groupe / autre ...".
linux
permissions
Yuval
la source
la source
devsgroupe permet cela.fooun membre des groupesfooetdevs, et assigneriez des fichiers partagés audevgroupe et des fichiers privés aufoogroupeRéponses:
Histoire
À l'origine, Unix n'avait que des autorisations pour l'utilisateur propriétaire et pour les autres utilisateurs: il n'y avait pas de groupe. Voir notamment la documentation d'Unix version 1
chmod(1). La rétrocompatibilité, si rien d'autre, nécessite donc des autorisations pour l'utilisateur propriétaire.Les groupes sont venus plus tard. Les listes de contrôle d'accès permettant d'impliquer plus d'un groupe dans les autorisations d'un fichier sont venues beaucoup plus tard.
Puissance expressive
Avoir trois autorisations pour un fichier permet des autorisations plus fines que d'en avoir seulement deux, à un coût très faible (beaucoup plus bas que les ACL). Par exemple, un fichier peut avoir le mode
rw-r-----: accessible en écriture uniquement par l'utilisateur propriétaire, lisible par un groupe.Un autre cas d'utilisation est les exécutables setuid qui ne sont exécutables que par un groupe. Par exemple, un programme dont le mode
rwsr-x---appartient àroot:adminautorise uniquement les utilisateurs duadmingroupe à exécuter ce programme en tant que root.«Il y a des autorisations que ce schéma ne peut pas exprimer» est un terrible argument contre lui. Le critère applicable est le suivant: existe-t-il suffisamment de cas exprimables communs qui justifient le coût? Dans ce cas, le coût est minime, surtout compte tenu des autres raisons du triptyque utilisateur / groupe / autre.
Simplicité
Avoir un groupe par utilisateur a une surcharge de gestion petite mais non négligeable. Il est bon que le cas extrêmement courant d'un fichier privé n'en dépende pas. Une application qui crée un fichier privé (par exemple un programme de livraison de courrier électronique) sait que tout ce qu'elle doit faire est de donner au fichier le mode 600. Elle n'a pas besoin de parcourir la base de données de groupe à la recherche du groupe qui ne contient que l'utilisateur - et que faire s'il n'y a pas un tel groupe ou plus d'un?
Venant d'une autre direction, supposons que vous voyez un fichier et que vous souhaitiez auditer ses autorisations (c'est-à-dire vérifier qu'elles sont ce qu'elles devraient être). C'est beaucoup plus facile lorsque vous pouvez aller «uniquement accessible à l'utilisateur, très bien, ensuite» que lorsque vous avez besoin de parcourir les définitions de groupe. (Une telle complexité est le fléau des systèmes qui font un usage intensif de fonctionnalités avancées telles que les listes de contrôle d'accès ou les capacités.)
Orthogonalité
Chaque processus effectue des accès au système de fichiers en tant qu'utilisateur et groupe particuliers (avec des règles plus compliquées sur les unités modernes, qui prennent en charge des groupes supplémentaires). L'utilisateur est utilisé pour beaucoup de choses, y compris pour tester la racine (uid 0) et l'autorisation de livraison de signal (basée sur l'utilisateur). Il existe une symétrie naturelle entre la distinction des utilisateurs et des groupes dans les autorisations de processus et la distinction des utilisateurs et des groupes dans les autorisations de système de fichiers.
la source
Les autorisations utilisateur / groupe / autres sur un fichier font partie de la conception Unix originale.
Oui, pratiquement tous les scénarios que je pourrais imaginer où la sécurité et le contrôle d'accès sont importants.
Exemple: vous souhaiterez peut-être donner à certains binaires / scripts sur un système un accès en exécution uniquement à
other, et limiter l'accès en lecture / écriture àroot.Je ne sais pas ce que vous avez en tête pour un modèle d'autorisation de système de fichiers qui n'a que des autorisations de propriétaire / groupe. Je ne sais pas comment vous pourriez avoir un système d'exploitation sécurisé sans l'existence d'une
othercatégorie.EDIT: Supposons que vous vouliez dire ici que les
group/otherautorisations sont tout ce qui serait nécessaire, alors je suggère de concevoir un moyen de gérer les clés cryptographiques ou un moyen que seuls les bons utilisateurs peuvent accéder à leur file d'attente de messagerie. Il existe des cas où une clé privée peut nécessiter strictement lauser:userpropriété, mais d'autres cas où il est logique de lui donner lauser:grouppropriété.Certes, cela se fait facilement, mais c'est tout aussi facile avec l'existence d'un
othergroupe ...J'ai mis en évidence la partie de votre déclaration qui semble réitérer mon point sur la nécessité logique d'une
othercatégorie dans les autorisations du système de fichiers Unix.Une telle conception de système de fichiers que vous semblez envisager (d'après ce que je peux dire) serait soit peu sûre, soit lourde. Unix a été conçu par des gens très intelligents, et je pense que leur modèle offre le meilleur équilibre possible entre sécurité et flexibilité.
la source
The UNIX Time-Sharing System, écrit par Dennis M. Ritchie et Ken Thomson en 1974, à l'origine, il y avait 7 bits pour les autorisations:Also given for new files is a set of seven protection bits. Six of these specify independently read, write, and execute permission for the owner of the file and for all other users.(Le septième bit était lesetuidbit).Oui, c'est une conception délibérée qui est présente sous UNIX depuis les premiers jours. Il a été implémenté sur des systèmes où la mémoire était mesurée en Ko et les processeurs étaient extrêmement lents par rapport aux normes actuelles. La taille et la vitesse de ces recherches étaient importantes. Les listes de contrôle d'accès auraient nécessité plus d'espace et auraient été plus lentes. Fonctionnellement, le
everyonegroupe est représenté par les autres drapeaux de sécurité.Les autorisations que j'utilise couramment pour accéder aux fichiers sont les suivantes: (J'utilise des valeurs binaires pour des raisons de simplicité et parce que c'est ainsi que je les définis habituellement.)
600ou400: Accès utilisateur uniquement (et oui, j'accorde un accès en lecture seule à l'utilisateur).640ou660: Accès utilisateur et groupe.644,666Ou664: utilisateur, groupe et autres accès. Tout schéma d'autorisation à deux niveaux ne peut gérer que deux de ces trois cas. Le troisième nécessiterait des ACL.Pour les répertoires et programmes que j'utilise couramment:
700ou500: Accès utilisateur uniquement750ou710: Accès en groupe uniquement755,777,775Ou751: utilisateur, groupe et autres accès. Les mêmes commentaires s'appliquent que pour les fichiers.Les éléments ci-dessus sont les plus couramment utilisés, mais pas une liste exhaustive des paramètres d'autorisation que j'utilise. Les autorisations ci-dessus combinées avec un groupe (parfois avec un bit de groupe collant sur les répertoires) ont suffi dans tous les cas où j'aurais pu utiliser une ACL.
Comme cela a été noté ci-dessus, il est très facile de répertorier l'autorisation dans une liste de répertoires. Si les listes de contrôle d'accès ne sont pas utilisées, je peux auditer les autorisations d'accès avec uniquement une liste de répertoires. Lorsque je travaille avec des systèmes basés sur ACL, je trouve très difficile de vérifier ou d'auditer les autorisations.
la source
Le système d'autorisation utilisateur / groupe / autre a été conçu avant l'invention des listes de contrôle d'accès. Cela remonte aux premiers jours d'UNIX, vous ne pouvez donc pas dire que le problème devrait être résolu avec les ACL. Même si le concept d'une ACL semble évident, il aurait impliqué une quantité importante [pour la journée] de frais supplémentaires pour stocker et gérer une quantité variable d'informations d'autorisation avec chaque fichier, plutôt qu'un montant fixe.
L'utilisation d'ACL pour tout signifie également que vous ne disposez pas d'un sous-ensemble bien défini des informations d'autorisation qui peuvent être affichées «en un coup d'œil». La sortie pour
ls -laffiche les autorisations standard (utilisateur / groupe / autre), le nom de l'utilisateur et du groupe, et une notation supplémentaire (par exemple+ou@signe) sur les entrées auxquelles une ACL est associée, le tout sur une seule ligne. Votre système exigerait qu'il identifie les «deux premiers» groupes dans la liste de contrôle d'accès pour fournir des fonctionnalités équivalentes.Comme point supplémentaire, un fichier doit toujours avoir un propriétaire dans le modèle UNIX car les ACL UNIX ne prévoient pas qui est autorisé à modifier l'ACL.
la source