0. Introduction
1. Relying on a Native NTFS ACL
2. Mapping the Users
3. Using as a POSIX ACL
4. Applying Windows-type inheritance
5. Mount Options
6. Limitations

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 : denials to owner (to exclude the rights given to group or world), grants to owner, denials to group, grants to groups, 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 (see limitations).

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. This deviates from the usual Windows behavior, based on inheritance, but conforms to Linux and provides the protection expected by applications designed for Linux. There is however an optional inheritance mode which can be used to get the windows behavior.

Initial rights may be changed by doing a chmod, chown or chgrp. For a directory, the rights for defined for reading and writing (but not for executing) are inheritable by files created by Windows in this directory. 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 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 interoperation of Windows and Linux permissions relies on a mapping of users defined in both systems, 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, the interoperation cannot be established, and ntfs-3g falls back into some restricted mode depending on the selected options.

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

# Typical pattern of a user mapping file for Windows 7 or earlier
# All users are in the same primary group
1000::S-1-5-21-1833069642-4243175381-1340018762-1002
1001::S-1-5-21-1833069642-4243175381-1340018762-1008
:500:S-1-5-21-1833069642-4243175381-1340018762-513

# Typical pattern of a user mapping file for Windows 8 or subsequent
# Each user is in his/her own primary group
1000:1000:S-1-5-21-1833069642-4243175381-1340018762-1002
1001:1001:S-1-5-21-1833069642-4243175381-1340018762-1008

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). If there are several users, it is essential that they be grouped the same way on Windows and Linux. By default, Windows 8 puts each user into a specific group, and earlier versions of Windows put all users into the same group. So, for compatibility with Windows 7, the primary group of all Linux users has to be the same, and the user mapping file should have a single group line with the first field left blank, and several user lines with the second field left blank. For compatibility with Windows 8, each Linux user should be in his/her own primary group, and there is no need for a dedicated group line, the user lines may have both a uid and a gid which map to the same Windows SID (see the consequences in limitations).

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, giving access to all files. Similarly, if no mapping is defined for the owner (or group) of some file, it appears as owned by root, and depending on protections, it may be accessible to root only.

Each uid value (first field) and each SID value (third field) is expected to be present in a single line. When several SIDs are defined for the same uid, only the first one can currently be set as the owner of a file upon file creation or chown.

A special line may be inserted at the end of the mapping file to define a pattern for a generic mapping of users for whom no explicit mapping is defined. The users resulting from this generic mapping are recognized by Windows as foreign users. 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

If no interoperation is wanted, and no real user mapping is required, such a generic mapping can be used, either explicitly, or by defining the mount options permissions or acl. Files defined on Linux as readable by anybody will still be readable by any user on Windows.

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. Designating another file system when mounting through /etc/fstab may fail when the file systems are mounted in parallel. 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). A simple way to determine the SIDs, is to apply ntfssecaudit to a file created on Windows by the user to be mapped:

# with ntfssecaudit version >= 1.4.0
ntfssecaudit -u file-created-on-Windows

A very basic utility ntfsusermap has also been developped to build a mapping file either on Windows or on Linux.

Two drafts on ACL features (IEEE 1003.1e/2c) have been defined by a POSIX working group. Though they never became standards, some Linux distributions have them integrated out of the box over ext2/ext3/ext4 file systems (Fedora, Ubuntu, Suse and others), but non-Linux systems (FreeBSD, OpenIndiana, etc.) do not support them. The POSIX ACLs make it possible to grant access rights for reading, writing and executing to any designated user or group, thus providing a better control on access to files in complex situations.

When this mode is used, permissions to access a file can be defined for several groups, and extra mapping lines may be used to define mappings for a few standard Windows groups. To be useful, the Linux users have to be put into secondary groups which should be mirrors of the group they are into on Windows.

# Extra group mappings usable when Posix ACLs are enabled :
:dialup:S-1-5-1
:network:S-1-5-2
:batch:S-1-5-3
:interactive:S-1-5-4
:service:S-1-5-6

Translations of rights defined in Windows or Linux can only be done according to the concepts available in the OS used, and another OS based on different concepts can only perceive the same rights as an approximation. When a Windows requirement conflicts with a Linux requirement, the option has been taken in favor of the latter, so that a Linux-only user always gets the same behavior as the one provided by an ext3 file system. Samba users having their shares on an ntfs-3g file system should get the same behavior as if the shares were on ext3. This does not mean the ACLs stored on NTFS are identical to those seen by a remote Windows client.

As a consequence, administration of complex rights should always be done on the same OS to really identify the consequences of the decisions taken. Though the Windows interpretation of the ACLs set from Linux are satisfactory, the Windows administration tools tend to reorder and merge the ACEs leading to a different interpretation. Likewise using Linux to update an ACL built by Windows leads to a different set of ACE likely to change the interpretation by Windows.

The POSIX ACL features are released as a disabled compile-time option in source tarballs. The option is not activated in the compiled versions. They can be enabled by defining the option --enable-posix-acls in the configure command.

The inherit mount option can be used to force the use of Windows rules when creating files. In such situation a newly created file or directory gets its permissions from its parent directory, and the initial permissions defined from Linux are ignored. This deviates from Linux rules, but provides a better compatibility with Windows. The most obvious difference is that new files are created with execute permissions on Windows, which is usually not the case and even discouraged on Linux.

Moreover, to prevent text editors from setting Linux-type permissions and overriding inheritance rules when they update a file or create a backup one, permissions cannot be changed through chmod, chown, chgrp or setfacl.

The owner and group of a file are not defined by inheritance, they are defined as the owner and group of the process which creates the file. This requires translating the process parameters to a Windows user SID and a group SIDs as defined by the user mapping, with each user in the same primary group in Windows and Linux. When a needed mapping is not defined, the administrator SID is generally used instead.

These differences in behavior make the option "inherit" not suitable and discouraged in most situations.

The permission checks are enabled according to the options defined at mount time or compile time, as shown in the table. uid and gid need an integer argument, fmask and dmask need an octal argument and permissions, acl and inherit need no argument (see examples below and the ntfs-3g manual).

Note: for pluggable devices, uid, gid fmask and dmask should be defined, so that standard protections are applied if a user mapping file is present on the plugged device, and fallback protections can be applied if the file is not present.

When creating new files, their ownership and permissions actually written on storage also depend on options selected and they may be different from how they are shown:

Examples:

# mount an internal hard disk, with standard Linux protections,
# provided a UserMapping file is present
mount -t ntfs-3g /dev/sda3 /mnt/shared

# mount a USB key, defining fallback protection parameters to
# use if no UserMapping file is present on the key
mount -t ntfs-3g -o gid=1000,uid=1000,dmask=022 /dev/sdf1 /media/key

# mount a hard disk, with new files getting their protections
# the Windows way (a UserMapping file is required)
mount -t ntfs-3g -o inherit /dev/sda3 /mnt/shared

After having migrated from a mode where permissions were not defined for each individual file, you may find unusual protection settings for your files and directories. For example, files which were created with protections disabled appear as owned by root and accessible to any user. It is recommended you set more appropriate ownerships and protections by issuing (recursive) chown or chmod commands for user files and user directories. By doing so the security descriptors will be recreated in a more efficient way. It is probably a bad idea to do the same on Windows system files, and on files created by packages installed for Windows.

The SIDs required to identify users and groups have to be originated from Windows. A user mapping file can however be copied to any partition, even if it were never formatted or used by Windows.

Some unusual basic rights configurations, where the group is denied rights granted to owner and to world (as in chmod 745,) are rejected by the Windows administration tools. They are however interpreted correctly by Windows itself. When using POSIX ACLs, more configurations are rejected by the Windows administration tools.

Similarly, when owner and group have the same identification (as is usual on Windows 8) and different permissions are set through chmod for owner and group, Windows cannot tell which permissions are intended for owner from those intended for group, and it merges them.

The base version is best suited for dual-boot systems with several users, complex user configurations will take profit from POSIX ACLs. User mapping features required for devices which may be plugged into multiple Windows or Linux systems are not available yet.