NTFS dispose d'une organisation de données natif lequel Windows utilise pour contrôler l'accès aux fichiers. Pour chaque fichier sont associés un propriétaire, un groupe, et une liste des utilisateurs qui sont autorisées ou refusées pour accéder au fichier pour un certain but. Les mêmes données peuvent être utilisées par Linux sur un ordinateur à double amorçage pour contrôler l'accès aux fichiers, mais que les concepts sous-jacents sont différents, approximations doivent être faits. Les autorisations Windows sont plus générales et certaines configurations peuvent pas être définis ou utilisés sous Linux.
Quoi qu'il en soit, à la fois Linux et Windows associent un propriétaire et un groupe de fichiers. Sous Linux, les droits fondamentaux pour accéder au fichier sont définies pour le propriétaire, le groupe et dans le monde. Dans certaines configurations Linux, droits similaires peuvent être accordées pour les utilisateurs et les groupes qui sont sans rapport avec le propriétaire. Dans Windows plusieurs utilisateurs individuels ou collectifs avec des droits spécifiques peuvent être définis pour un fichier. La liste des droits attachés à un fichier est connu comme un ACL (Access Control List), et un ensemble de droits définis pour un utilisateur est connu comme un ACE (Access Control Entry).
Dans une première extension de niveau, nous ne traiterons que les droits d'accès Linux traditionnels associés à un propriétaire unique, un seul groupe et les autres utilisateurs. Dans une autre extension, l'octroi ou des droits à plusieurs utilisateurs individuels ou des groupes niant est rendu possible selon le projet de définition des ACLs POSIX.
Pour définir l'interopérabilité des accès aux fichiers pour Windows et Linux, deux relations doivent être établies entre les concepts dans les deux systèmes: l'un concernant les utilisateurs et les groupes, et un autre concernant les droits d'accès.
L'utilisation d'un NTFS ACL natif
Dans le prolongement ntfs-3g proposé, seules les données que définis pour NTFS sont utilisés. Les droits pour Linux propriétaire, le groupe et dans le monde à lire, écrire ou exécuter un fichier ne sont pas stockées sur le système NTFS, mais sont convertis vers ou à partir d'une ACL lorsque Linux définit ou récupère les paramètres de sécurité d'un fichier. En conséquence toutes les données de sécurité peuvent être sauvegardés par des outils standards de Windows, alors que les outils standards de sauvegarde Linux stockent la conversion aux droits Linux, perdant ainsi quelques informations qui peut être perçue sous Windows après la restauration.
L'ACL qui accorde ou refuse les autorisations pour le propriétaire, le groupe ou est utilisé pour construire les droits des propriétaires Linux, groupe ou mondiaux correspondants comme retourné à stat () et visualisable par la commande standard "ls -l".
De même, quand un fichier est chmod'ed, une ACL est construit selon les droits accordés à l'utilisateur, groupe et monde. L'ACL, composé de deux à sept ACE reflète autorisations Linux: subventions pour le propriétaire, les refus de propriétaire (pour exclure les droits accordés à un groupe ou dans le monde), les subventions à un groupe, démentis à un groupe, les subventions à monde, et des subventions pour les administrateurs et le système (les administrateurs et le système sont toujours accordées de plein droit). Une autre série de ACE est construite lorsque le propriétaire est un administrateur parce que dans ce propriétaire de la situation, le groupe et l'administrateur sont le même, d'ACE afin redondante à définir. Une situation similaire se pose lorsque l'utilisateur et le groupe ont la même identification, nécessitant un troisième ensemble d'ACE.
Configurations ACL spéciaux sont également utilisés pour représenter les drapeaux collantes, setuid et setgid qui ont pas vraiment d'équivalent dans Windows.
Lorsque vous créez un fichier, son propriétaire et les permissions initiales sont définis selon le propriétaire des paramètres du procédé et de la création. Toutefois, une option de montage peut être utilisé pour hériter des réglages initiaux du répertoire parent, comme il est habituel avec Windows.
Droits initiaux (définis lors de la création ou héritées du passé) peuvent être modifiées en faisant un chmod, chown ou chgrp. Pour un répertoire, les nouveaux droits sont héritables par les fichiers créés par Windows dans ce répertoire (ou Linux si l'option d'héritage est activé). Cependant, gardez à l'esprit que chmod pouvez uniquement définir des autorisations qui ont un sens pour Linux.
Bâtiment Linux autorisations et obtenir propriétaire et le groupe d'un ACL est assez complexe, de sorte que, lorsque héréditaire, les résultats sont conservés dans une mémoire cache pour une utilisation ultérieure. Ce que cache est très efficace comme une seule entrée doit être maintenu pour tous les fichiers qui ont le même ensemble d'autorisations, propriétaire et le groupe.
Cartographier les utilisateurs
Le système d'autorisation entière est basée sur une cartographie des utilisateurs de Windows pour les utilisateurs de Linux, généralement stockées dans un fichier nommé UserMapping situé dans le répertoire cachés .NTFS-3G du système de fichiers NTFS. Lorsque vous utilisez plusieurs systèmes de fichiers NTFS, ce fichier doit être répliquée sur chacun d'eux, sauf un emplacement commun est désigné au moment du montage. Si le fichier est manquant, ntfs-3g agit comme dans les versions standards ntfs-3g, accordant un accès complet à tous les utilisateurs si l'application de l'autorisation héritée attribue à créé des fichiers.
Le fichier de mappage est organisé en lignes avec trois champs séparés par deux points, tels que:
500 :: S-1-5-21-1833069642-4243175381-1340018762-1008
: 500: S-1-5-21-1833069642-4243175381-1340018762-513
Le premier champ est le uid (ou l'identification de l'utilisateur) d'un utilisateur de Linux à la carte, le deuxième champ est le gid (identification de groupe), et le troisième champ est l'identifiant correspondant d'utilisateur Windows (connu comme un SID). L'uid ou gid champs peuvent être laissés vides quand ils correspondent SID différent de. Les lignes dont le premier caractère est un '#' sont ignorées.
Pas de mappage explicite est nécessaire pour les groupes standard, telles que le groupe "Tous les utilisateurs" ou d'un groupe "Administrateur". Si aucun mappage est défini pour un utilisateur ou un groupe, les droits root sont utilisés. De même, si aucun mappage utilisateur est défini pour certains fichiers, il apparaît comme possédé par root, et en fonction des protections, il peut être accessible uniquement pour root.
Bien que plusieurs SID peut être défini pour un uid, seul le premier est actuellement défini comme le propriétaire d'un fichier tel que défini dans la création ou chown fichier.
Une ligne spéciale peut être inséré à la fin du fichier de mappage pour définir un motif pour une correspondance implicite des utilisateurs pour lesquels aucun mappage explicite est défini. Cette cartographie implicite est pas reconnu par Windows et ne peut être utilisé pour les comptes de linux-seulement. Les champs uid et gid doivent être laissés vides, et le dernier numéro dans le SID doit être supérieur au nombre équivalent pour tout utilisateur mappé explicitement, par exemple:
:: S-1-5-21-1833069642-4243175381-1340018762-10000
L'emplacement du fichier de mappage peut être redéfini par l'option de montage "usermapping = chemin". Si le chemin est absolu, il désigne un fichier sur un système de fichiers monté précédemment, si le chemin est relatif, il désigne un fichier relatif à la racine du système de fichiers NTFS est monté. Pas de protection est actuellement fixé ou vérifié sur le fichier de mapping lui-même. Il devrait évidemment être accessible uniquement par un administrateur (implicitement mappé à la racine).
Si aucun fichier de mappage est trouvée, une tentative de construire un simple mapping par défaut de l'utilisateur est faite par la cartographie de l'UID et le GID défini dans la commande mount pour le propriétaire de la racine du système de fichiers monté. Ceci est possible seulement si uid et gid sont définis en tant qu'utilisateur non root et le propriétaire du système de fichier est pas un administrateur. Cette cartographie par défaut est le plus adapté pour les systèmes de fichiers enfichables (tels que des clés USB) qui doivent être utilisés sur plusieurs systèmes Linux. Le propriétaire doit être défini sur Windows.
Un utilitaire usermap très basique a été développé pour créer un fichier de mappage soit sous Windows ou Linux. Il prend la liste des partitions à partager entre les systèmes comme arguments, avec la partition système Windows comme premier argument:
c:> usermap c: d:
[Root @ home du système] # umount / dev / sda3
[Root @ home du système] # umount / dev / sda6
[Root accueil du système de @] # usermap / dev / sda3 / dev / sda6
Il suffit de scanner les fichiers de noms d'utilisateur dans "Documents and Settings" et les propriétaires de fichiers dans les partitions désignés. Pour chaque propriétaire a trouvé qu'il demande pour l'utilisateur ou le groupe Linux correspondant.
Lors de l'exécution sur les machines Windows, le fichier de mappage résultant est écrit dans le fichier dans le répertoire UserMapping .NTFS-3G de la seconde partition désigné (ou le premier si pas plus).
En ne peut être exécuté sur Linux en tant que root et les partitions désignés démonté. Le fichier de mappage résultant est écrite à déposer UserMapping dans le répertoire courant et doit être déplacé par la suite au répertoire .NTFS-3G après avoir monté le système de fichiers NTFS, ou déplacés à l'endroit désigné dans les options de montage. Il doit être démonté et monté de nouveau pour la cartographie à prendre en compte
Quoi de neuf dans cette version:.
- Cette version corrige le propriétaire des fichiers quand il est différent du propriétaire Windows.
- les contrôles d'autorisation sont effectués lors de l'ouverture d'un répertoire par open (2).
- Cette version a également été mis à jour pour ntfs-3g-1,2918.
Limitations :
- Les versions téléchargeables ont été testés uniquement sur le dessus de processeurs i386 et x86_64. Leur interopérabilité n'a été testé contre Windows XP SP2.
- Les SID nécessaires pour identifier les utilisateurs et les groupes doivent être construits sur Windows. Un fichier de mappage utilisateur peut cependant être copié sur une partition, même si elle était jamais formaté ou utilisé par Windows.
- Certains configuration inhabituelle de l'homme, où le groupe est privé des droits accordés aux propriétaires et monde (comme dans chmod 745) sont rejetés par les outils d'administration Windows. Ils sont cependant correctement interprétés par Windows lui-même.
- La version de base est le mieux adapté pour les systèmes dual-boot avec plusieurs utilisateurs, les configurations complexes des utilisateurs vont profiter de ACLs POSIX. fonctions de cartographie de l'utilisateur nécessaires pour les dispositifs qui peuvent être branchés sur plusieurs systèmes Windows ou Linux ne sont pas encore disponibles, à l'exception de la cartographie seul utilisateur par défaut.
- L'octroi de droits spécifiques pour accéder à un fichier pour les utilisateurs ou les groupes qui ne sont pas propriétaire ou le groupe du fichier est seulement possible par l'utilisation d'ACL POSIX, mais il est impossible d'accorder ou de refuser des droits pour éradiquer grâce à l'utilisation d'ACL.
Commentaires non trouvées