Historique
A l'origine, Unix n'avait des permissions que pour l'utilisateur propriétaire, et pour les autres utilisateurs :il n'y avait pas de groupes. Voir la documentation d'Unix version 1, en particulier chmod(1) . Ainsi, la rétrocompatibilité, si rien d'autre, nécessite des autorisations pour l'utilisateur propriétaire.
Les groupes sont venus plus tard. Les ACL permettant d'impliquer plus d'un groupe dans les permissions 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 inférieur aux 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 concerne les exécutables setuid qui ne sont exécutables que par un groupe. Par exemple, un programme avec le mode rwsr-x--- propriété de root:admin n'autorise que les utilisateurs dans le admin groupe pour exécuter ce programme en tant que root.
"Il y a des permissions que ce schéma ne peut pas exprimer" est un argument terrible contre lui. Le critère applicable est, y a-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 charge de gestion faible mais non négligeable. Il est bon que le cas extrêmement courant d'un dossier privé n'en dépende pas. Une application qui crée un fichier privé (par exemple, un programme de livraison de courrier électronique) sait qu'il lui suffit de donner au fichier le mode 600. Elle n'a pas besoin de parcourir la base de données des groupes à 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 souhaitez auditer ses autorisations (c'est-à-dire vérifier qu'elles sont ce qu'elles devraient être). C'est beaucoup plus facile lorsque vous pouvez choisir "uniquement accessible à l'utilisateur, fin, suivant" que lorsque vous devez 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 ACL ou les capacités.)
Orthogonalité
Chaque processus effectue des accès au système de fichiers en tant qu'utilisateur particulier et groupe particulier (avec des règles plus compliquées sur les unix modernes, qui prennent en charge des groupes supplémentaires). L'utilisateur est utilisé pour beaucoup de choses, y compris le test de la racine (uid 0) et l'autorisation de livraison du 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 du système de fichiers.
Est-ce une conception délibérée ou un patch ? C'est-à-dire - les autorisations de 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 ?
L'utilisateur/le groupe/les autres autorisations sur un fichier font partie de la conception Unix d'origine.
Existe-t-il un scénario où le schéma utilisateur/groupe/autre est utile mais un schéma groupe/propriétaire ne suffit pas ?
Oui, pratiquement tous les scénarios que je peux imaginer où la sécurité et le contrôle d'accès sont importants.
Exemple :Vous voudrez peut-être donner à certains fichiers binaires/scripts sur un système un accès en exécution uniquement à other , et gardez l'accès en lecture/écriture limité à 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'un other catégorie.
MODIF : Supposons que vous vouliez dire ici group/other les autorisations 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 puissent accéder à leur spool de courrier. Il y a des cas où une clé privée peut nécessiter strictement user:user propriétaire mais d'autres cas où il est logique de lui donner user:group propriété.
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.
Certes, cela se fait facilement, mais cela se fait tout aussi facilement avec l'existence d'un other groupe...
autoriser uniquement le propriétaire (par exemple, le service système) à écrire dans un fichier, autoriser uniquement un certain groupe à lire et refuser tous les autres accès - le problème avec cet exemple est qu'une fois que l'exigence est qu'un groupe ait un accès en écriture, l'utilisateur/groupe/autre échoue avec cela. La réponse pour les deux utilise les ACL et ne justifie pas, à mon humble avis, l'existence d'autorisations de propriétaire.
J'ai mis en évidence la partie de votre déclaration qui semble réitérer mon point sur la nécessité logique d'un other caté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 peu maniable. Unix a été conçu par des personnes très intelligentes, et je pense que leur modèle offre le meilleur équilibre possible entre sécurité et flexibilité.
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 ?
Oui, c'est une conception délibérée qui est présente dans UNIX depuis les premiers jours. Il a été implémenté sur des systèmes où la mémoire était mesurée en Ko et où 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 everyone groupe est représenté par les autres indicateurs de sécurité.
Existe-t-il un scénario où le schéma utilisateur/groupe/autre est utile mais un schéma groupe/propriétaire ne suffit pas ?
Les autorisations que j'utilise couramment pour l'accès aux fichiers sont :(j'utilise des valeurs de bit pour plus de simplicité et parce que c'est ainsi que je les définit habituellement.)
600ou400:Accès utilisateur uniquement (et oui, j'accorde un accès en lecture seule à l'utilisateur).640ou660:accès des utilisateurs et des groupes.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. La troisième nécessiterait des ACL.
Pour les répertoires et les programmes que j'utilise couramment :
700ou500: Accès utilisateur uniquement750ou710: Accès de groupe uniquement755,777,775, ou751: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 ne constituent pas une liste exhaustive des paramètres d'autorisation que j'utilise. Les autorisations ci-dessus combinées à un groupe (parfois avec un groupe collant sur les répertoires) ont suffi dans tous les cas où j'aurais pu utiliser une ACL.
Comme indiqué ci-dessus, il est très facile de répertorier l'autorisation dans une liste de répertoires. Si les ACL 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 qu'il est très difficile de vérifier ou d'auditer les autorisations.