ntfs-3g (Ownership and Permissions Support) For Linux

NTFS has a native data organisation which Windows uses to control access to files. To each file are associated an owner, a group, and a list of users who are allowed or denied to access the file for some purpose. The same data can be used by Linux on a dual-boot computer to control access to files, but as the underlying concepts are different, approximations have to be made. The Windows permissions are more general and some configurations cannot be defined or used in Linux.

Anyway, both Linux and Windows associate an owner and a group to files. In Linux, the basic rights to access the file are defined for owner, group and world. In some Linux configurations, similar rights can be granted to users and groups which are unrelated to the owner. In Windows multiple individual or collective users with specific rights may be defined for a file. The list of rights attached to a file is known as an ACL (Access Control List), and a set of rights defined for a user is known as an ACE (Access Control Entry).

In a first level extension, we will only deal with the traditional Linux access rights associated to a single owner, a single group and other users. In a further extension, granting or denying rights to multiple individual users or groups is made possible according to the draft definition of Posix ACLs.

To define interoperability of access to files for Windows and Linux, two relations have to be established between concepts in both systems : one regarding the users and groups, and another regarding the access rights.

In the proposed ntfs-3g extension, only data as defined for NTFS are used. The Linux rights for owner, group and world to read, write or execute a file are not stored on NTFS but are converted to or from an ACL when Linux sets or retrieves security parameters of a file. As a consequence all security data may be saved by standard Windows tools, whereas standard Linux backup tools store the conversion to Linux rights, thus losing some information which may be perceived under Windows after restoring.

The ACL which grants or denies permissions to the owner, group or world is used to build the corresponding Linux owner, group or world permissions as returned to stat() and displayable by the standard command "ls -l".

Similarly, when a file is chmod'ed, an ACL is built according to rights granted to user, group and world. The ACL, composed of two to seven ACE's reflects Linux permissions : grants to owner, denials to owner (to exclude the rights given to group or world), grants to group, denials to group, grants to world, and grants to administrators and system (the administrators and system are always granted full rights). A different set of ACE's is built when the owner is an administrator because in this situation owner, group and administrator are the same, so redundant ACE's have to be defined. A similar situation arises when the user and the group have the same identification, requiring a third set of ACE's.

Special ACL configurations are also used to represent the sticky, setuid and setgid flags which have no real equivalent in Windows.

When creating a file, its ownership and initial permissions are defined according to owner of process and creation parameters. However a mount option may be used to inherit the initial settings from parent directory, as is customary with Windows.

Initial rights (defined at creation time or inherited) may be changed by doing a chmod, chown or chgrp. For a directory, the new rights are inheritable by files created by Windows in this directory (or by Linux if inheritance option is activated). However keep in mind that chmod can only set permissions which have a meaning to Linux.

Building Linux permissions and getting owner and group from an ACL is rather complex, so, when inheritable, the results are kept in a memory cache for further use. This cacheing is very efficient as a single entry has to be maintained for all files which have the same set of permissions, owner and group.

The whole permission system is based on a mapping of Windows users to Linux users, generally stored in a file named UserMapping located in the hidden directory .NTFS-3G of the NTFS file system. When using several NTFS file systems, this file has to be replicated on each of them unless a common location is designated at mount time. If the file is missing, ntfs-3g acts as in standard ntfs-3g versions, granting full access to all users though applying inherited permission attributes to created files.

The mapping file is organized in lines with three fields separated by colons, such as :

500::S-1-5-21-1833069642-4243175381-1340018762-1008 :500:S-1-5-21-1833069642-4243175381-1340018762-513

The first field is the uid (or user identification) of a Linux user to map, the second field is the gid (group identification), and the third field is the corresponding Windows user id (known as a SID). The uid or gid fields may be left blank when they match different SID's. Lines whose first character is a '#' are ignored.

No explicit mapping is needed for standard groups, such as the "All Users" group or "Administrator" group. If no mapping is defined for some user or group, root rights are used. Similarly, if no user mapping is defined for some file, it appears as owned by root, and depending on protections, it may be accessible to root only.

Though several SID may be defined for a uid, only the first one is currently set as the owner of a file as defined in file creation or chown.

A special line may be inserted at the end of the mapping file to define a pattern for an implicit mapping of users for whom no explicit mapping is defined. This implicit mapping is not recognized by Windows and may only be used for linux-only accounts. The uid and gid fields must be left void, and the last number in the SID must be greater than the equivalent number for any explicitly mapped user, for instance :

::S-1-5-21-1833069642-4243175381-1340018762-10000

The location of the mapping file may be redefined by the mount option "usermapping=path". If the path is absolute, it designates a file on a previously mounted file system, if the path is relative, it designates a file relative to the root of the NTFS file system being mounted. No protection is currently set or checked on the mapping file itself. It should obviously be only accessible by an Administrator (implicitly mapped to root).

If no mapping file is found, an attempt to build a default single user mapping is made by mapping the uid and gid defined in the mount command to the owner of the root of the mounted file system. This is only possible if uid and gid are defined as a non-root user and the owner of the file system is not an Administrator. This default mapping is most suited for pluggable file systems (such as USB keys) which have to be used on several Linux systems. The owner has to be defined on Windows.

A very basic utility usermap has been developped to build a mapping file either on Windows or on Linux. It takes the list of partitions to share among systems as arguments, with the Windows system partition as first argument :

c:>usermap c: d:

[root@system home]# umount /dev/sda3 [root@system home]# umount /dev/sda6 [root@system home]# usermap /dev/sda3 /dev/sda6

It just scan files for user names in "Documents and Settings" and file owners in the designated partitions. For each owner found it asks for the corresponding Linux user or group.

When executing on Windows machines, the resulting mapping file is written to file UserMapping in the directory .NTFS-3G of the second designated partition (or the first one if no more).

In can only be executed on Linux as root and with the designated partitions unmounted. The resulting mapping file is written to file UserMapping in current directory and has to be moved subsequently to the directory .NTFS-3G after having mounted the NTFS file system, or moved to the location designated in mount options. It has to be unmounted and mounted again for the mapping to be taken into account.