Comment fonctionnent les permissions / attributes de files? Au niveau du kernel, niveau FS ou les deux?

Le kernel et le système de files jouent un rôle. Les permissions sont stockées dans le système de files, il doit donc y avoir un endroit pour stocker les informations dans le format du système de files. Les permissions sont appliquées et communiquées aux applications par le kernel, de sorte que le kernel doit implémenter des règles pour déterminer ce que l'information stockée dans le système de files signifie.

"Autorisations de file Unix" fait reference à un système d'autorisation traditionnel qui implique trois actions (lecture, écriture, exécution) contrôlées via trois types de rôles (user, groupe, autre). Le travail du système de files consiste à stocker 3 × 3 = 9 bits d'information. Le travail du kernel consiste à interpréter ces bits comme des permissions; en particulier, lorsqu'un process tente une opération sur un file, le kernel doit déterminer, count tenu de l'user et des groupes que le process exécute, les bits d'autorisation du file et l'opération demandée, s'il faut autoriser l'opération. ("Autorisations de file Unix" inclut également généralement les bits setuid et setgid , qui ne sont pas des permissions à proprement parler.)

Les systèmes unix modernes peuvent prendre en charge d'autres forms d'permissions. La plupart des systèmes unix modernes (Solaris, Linux, * BSD) prennent en charge les lists de contrôle d'access qui permettent d'assigner des permissions de lecture / écriture / d'excécution à plus d'un user et plus d'un groupe pour chaque file. Le système de files doit avoir de la place pour stocker ces informations supplémentaires, et le kernel doit inclure du code pour searchr et utiliser cette information. Ext2, reiserfs, btrfs, zfs et la plupart des autres formats de filesystems unix modernes définissent un location pour stocker de telles ACL. Mac OS X prend en charge un set différent d'ACL qui inclut des permissions non traditionnelles telles que «append» et «create sous-directory»; le format de système de files HFS + les prend en charge. Si vous montez un volume HFS + sous Linux, ces ACL ne seront pas appliquées puisque le kernel Linux ne les prend pas en charge.

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

Les versions successives de Windows ont ajouté le support pour plus de types d'autorisation. Le système de files NTFS a été étendu pour stocker ces permissions supplémentaires. Si vous accédez à un système de files avec les nouvelles permissions sur un ancien operating system, le operating system ne sera pas informé de ces nouvelles permissions et ne les appliquera donc pas. Inversement, si vous accédez à un système de files plus ancien avec un operating system plus récent, il ne contiendra pas les nouvelles permissions et il appartient au operating system de fournir des solutions de rechange raisonnables.

Pour pouvoir utiliser certains droits, le kernel et le système de files doivent les prendre en charge. Si le système de files ne prend même pas en charge les droits d'access les plus élémentaires, le code du système de files doit les simuler (par exemple avec l'option de assembly umask pour vfat).

Je crois comprendre que le kernel implémente les inodes dans VFS. les inodes contiennent des informations d'autorisation (UNIX et ACL) ainsi que d'autres métadonnées et le système de files peut étendre l'inode pour append des fonctionnalités. Si vous êtes intéressé, lisez sur Linux VFS – trucs génial si vous n'êtes pas un programmeur de systèmes.

En règle générale, l'autorisation des files et les attributes des files sont stockés dans le file [le path exact dépend du système de files en question (ext3 / 4, riser, NTFS etc …)] mais sont utilisés par le kernel pour forcer quelque chose.

Par exemple Le kernel dans * nix comme sistema est "la chose" qui connaît la signification de l'UID associé à un file / directory. Un UID de file est simplement un nombre stocké à côté d'un file certan par le système de files mais la «traduction» d'un tel numéro à un certain user (et les droits correspondants pour faire quelque chose) est fait par le kernel.