File Ownership and Permissions

Updated: Feb 1st, 2012


Advanced NTFS-3G is moving !




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.

Relying on a Native NTFS ACL

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.

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 the inherit mount option may be used to inherit the initial permission 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 for reading and writing (but not for executing) are inheritable by files created by Windows in this directory (Linux follows the same rules 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.

Mapping the Users

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 :

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. Defining a uid and a gid for the same SID may lead to bad compatibility with Windows and should be avoided, moreover for better compatibility the (user, default group) pairs should be the same on both systems.

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.

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 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 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. 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 secaudit to a file created on Windows by the user to be mapped :

# with secaudit version >= 1.3.22
ntfs-3g.secaudit -vv file-created-on-Windows | grep ':dec'

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

This detailed example also shows how permissions can be set up for a family environment.

Using as a POSIX ACL

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 file systems (Fedora, Suse and others, also Solaris in a different implementation.) The POSIX ACLs make it possible to grant access rights for reading, writing and execution to any designated user or group, thus providing a better control on access to files in complex situations.

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.

With older versions, files created in directories with a default POSIX ACL still had the umask applied. This has been fixed in cooperation with the fuse project. With Linux kernels 2.6.29 and 2.6.30 the fuse kernel module has to be recompiled. The fixed module and the script for recompiling are available in fuse-module.tgz. No fix is needed since kernel 2.6.31.

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.


Mount Options

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).


File access checks
Conditions
No permission checks No uid, gid, fmask, dmask, umask or permissions or acl option,
and no user mapping file found
Same ownership (uid, gid) and permissions for all files and directories (restricted by fmask, dmask and umask) uid or gid or fmask or fmask or umask defined,
and no user mapping file found
Standard permission checks, according to ownership and mode, and POSIX ACLs not used
(uid, gid, fmask dmask and umask ignored)
No uid or gid or fmask or fmask or umask or acl defined,
permissions defined,
and no user mapping file found
POSIX ACLs not selected at compile-time,
and user mapping file found
POSIX ACLs selected at compile-time,
permissions defined,
and user mapping file found
Permissions according to ownership, mode and POSIX ACLs
(uid, gid, fmask, dmask and umask ignored)
POSIX ACLs selected at compile-time,
No permissions,
and acl defined
POSIX ACLs selected at compile-time,
No permissions,
and user mapping file found

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 :

File creation parameters
Conditions
New files are owned by root and can be accessed by anybody
No uid, gid, fmask, dmask, umask
or permissions defined,
No user mapping file found.
New files created as owned by root and accessed by anybody, but processed according to uid, gid, fmask, dmask and umask uid, gid, fmask, dmask or umask defined
No user mapping file found.
New files are owned by creator and inherit their permissions from parent directory (Windows behavior)
User mapping file not found
No uid, gid, fmask, dmask, umask defined,
permissions defined,
inherit option defined.
User mapping file found
inherit option defined.
Ownership and permissions defined in creation parameters (POSIX behavior) POSIX ACLs not selected at compile-time,
User mapping file not found,
No uid, gid, fmask, dmask, umask defined,
permissions defined,
No inherit option.
POSIX ACLs not selected at compile-time,
User mapping file found,
No inherit option.
POSIX ACLs selected at compile-time,
User mapping file found,
No inherit option,
No default ACL on parent directory.
New files are owned by creator, with permissions defined in parent directory (POSIX draft behavior) POSIX ACLs selected at compile-time,
User mapping file found,
No inherit option,
Default ACL defined on parent directory.

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
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.

Limitations

The SIDs required to identify users and groups have to be built on Windows. A user mapping file can however be copied on 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.

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.


To report any problem, please post to the support forum hosted by Tuxera

Page is maintained by Jean-Pierre André