Advanced NTFS-3G is moving !
Please visit us on http://jp-andre.pagesperso-orange.fr/advanced-ntfs-3g.html
|
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.
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.
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-10000If 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.
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.
|
|
|
| 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 |
|
|
|
| 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.
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