Comment fonctionnent les autorisations / attributs de fichier? Niveau noyau, niveau FS ou les deux?


8

Une question qui m'est venue à l'esprit plus tôt: les autorisations / attributs de fichier dépendent-ils du système d'exploitation (et donc du noyau) ou dépendent-ils du système de fichiers? Il me semble que la deuxième alternative est la plus logique, mais je n'ai jamais entendu parler des reiserfsautorisations de fichiers, par exemple: uniquement des "autorisations de fichiers Unix". D'autre part, pour citer un article de Wikipedia :

À mesure que de nouvelles versions de Windows sont sorties, Microsoft a ajouté à l'inventaire des attributs disponibles sur le système de fichiers NTFS

ce qui semble suggérer que les attributs des fichiers Windows sont en quelque sorte liés au système de fichiers.

Quelqu'un peut-il m'éclairer?

Réponses:


7

Le noyau et le système de fichiers jouent tous deux un rôle. Les autorisations sont stockées dans le système de fichiers, il doit donc y avoir un endroit pour stocker les informations au format du système de fichiers. Les autorisations sont appliquées et communiquées aux applications par le noyau, de sorte que le noyau doit implémenter des règles pour déterminer la signification des informations stockées dans le système de fichiers.

Les «autorisations de fichier Unix» font référence à un système d'autorisation traditionnel qui implique trois actions (lecture, écriture, exécution) contrôlées via trois types de rôles (utilisateur, groupe, autre). Le travail du système de fichiers consiste à stocker 3 × 3 = 9 bits d'informations. Le travail du noyau est d'interpréter ces bits comme des autorisations; en particulier, lorsqu'un processus tente une opération sur un fichier, le noyau doit déterminer, compte tenu de l'utilisateur et des groupes sous lesquels le processus s'exécute, les bits d'autorisation du fichier et l'opération demandée, s'il faut autoriser l'opération. (Les «autorisations de fichier Unix» incluent également généralement les bits setuid et setgid , qui ne sont pas à proprement parler des autorisations.)

Les systèmes Unix modernes peuvent prendre en charge d'autres formes d'autorisations. La plupart des systèmes Unix modernes (Solaris, Linux, * BSD) prennent en charge des listes de contrôle d'accès qui permettent d'attribuer des autorisations de lecture / écriture / exécution à plusieurs utilisateurs et plusieurs groupes pour chaque fichier. Le système de fichiers doit avoir de la place pour stocker ces informations supplémentaires, et le noyau doit inclure du code pour rechercher et utiliser ces informations. Ext2, reiserfs, btrfs, zfs et la plupart des autres formats de système de fichiers Unix modernes définissent un emplacement pour stocker ces ACL. Mac OS X prend en charge un ensemble différent d'ACL qui incluent des autorisations non traditionnelles telles que «ajouter» et «créer un sous-répertoire»; le format de système de fichiers HFS + les prend en charge. Si vous montez un volume HFS + sur Linux, ces ACL ne seront pas appliquées car le noyau Linux ne les prend pas en charge.

À l'inverse, il existe des systèmes d'exploitation et des systèmes de fichiers qui ne prennent pas en charge le contrôle d'accès. Par exemple, FAT et ses variantes ont été conçues pour les systèmes d'exploitation à utilisateur unique et les supports amovibles et ses autorisations sont limitées à la lecture / lecture-écriture et cachées / visibles. Ce sont les autorisations appliquées par DOS . Si vous montez un système de fichiers ext2 sous DOS, il n'appliquera pas les autorisations ext2. Inversement, si vous accédez à un système de fichiers FAT sous Linux, tous les fichiers auront les mêmes autorisations.

Les versions successives de Windows ont ajouté la prise en charge de plusieurs types d'autorisations. Le système de fichiers NTFS a été étendu pour stocker ces autorisations supplémentaires. Si vous accédez à un système de fichiers avec les autorisations les plus récentes sur un ancien système d'exploitation, le système d'exploitation ne connaîtra pas ces autorisations plus récentes et ne les appliquera donc pas. Inversement, si vous accédez à un système de fichiers plus ancien avec un système d'exploitation plus récent, il ne contiendra pas les nouvelles autorisations et il appartient au système d'exploitation de fournir des solutions de rechange raisonnables.


"Le travail du noyau consiste à interpréter ces bits comme des autorisations; en particulier, lorsqu'un processus tente une opération sur un fichier, le noyau doit déterminer [...]" Cela ne signifie-t-il pas qu'un noyau pourrait en théorie être modifié en ignorer tout cela et lire les données de toute façon? (Une sorte d'accès direct au disque) Ou y a-t-il autre chose qui empêche cela?
Overmind

@Overmind Bien sûr. Le code du noyau a accès à tout. Le disque ne sait rien des processus, des utilisateurs ou des autorisations. Le noyau dit au disque «donnez-moi le bloc 232876» et le disque répond avec le contenu du bloc. Déterminer quels processus peuvent accéder à quels blocs (ou quelles parties de blocs) est le travail du noyau.
Gilles 'SO- arrête d'être méchant'

4

Pour l' utilisateur certains droits tant le noyau et le système de fichiers doit les soutenir. Si le système de fichiers ne prend même pas en charge les droits d'accès les plus élémentaires, le code du système de fichiers doit les simuler (par exemple avec l'option de montage umaskpour vfat).


3

Ma compréhension est que le noyau implémente des inodes dans VFS. les inodes contiennent des informations sur les autorisations (UNIX et ACL) ainsi que d'autres métadonnées et le système de fichiers peut étendre l'inode pour ajouter des fonctionnalités. Si vous êtes intéressé, lisez sur Linux VFS - des trucs gore si vous n'êtes pas un programmeur de systèmes.


1

En règle générale, l'autorisation des fichiers et les attributs des fichiers sont stockés dans filesistem [la manière exacte dépend du système de fichiers en question (ext3 / 4, riser, NTFS etc ...)] mais est utilisée par le noyau, normalement pour appliquer quelque chose.

Par exemple Le noyau dans * nix comme sistema est "la chose" qui connaît la signification de l'UID associé à un fichier / répertoire. Un UID de fichier est simplement un numéro stocké à côté d'un fichier certan par le système de fichiers mais la "traduction" de ce numéro à un certain utilisateur (et les droits correspondants pour faire quelque chose ou non) est effectuée par le noyau.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.