Hi,
I'm forwarding below and in attachement Jean-Pierre's email and initial permission handling patch against the latest ntfs-3g CVS (it applies perfectly cleanly) with his agreement for further shared review, discussion, improvement, and testing.
Thank you Jean-Pierre! :-))
Szaka
---------- Forwarded message ----------
Date: Wed, 05 Sep 2007 21:07:25 +0200
From: "[ISO-8859-1] Jean-Pierre André" <[EMAIL PROTECTED]>
To: Szabolcs Szakacsits <[EMAIL PROTECTED]>, "mailto:szaka"@sienet.hu
Subject: Permission handling in ntfs-3g : there it is
Hi, Szaka
Here it is !
Attached is a diff to cvs for a near full implementation of permission
mapping between Linux and Windows, and even more : I have followed
(most of) your recommendations. I have even developped a basic tool
(to be executed on Windows) to assist in building the user mapping.
It has passed a first level of verifications, but no need to say it has not
been fully tested and the hard work is still ahead.
I will not be able to work on it for ten days or so. If there is any
problems with this sending (wrong files or whatever), please inform me
no later than friday morning, so that I can fix it.
Please enjoy and return remarks on concepts and implementation (even in
coding style, still subject to improvement).
The text which follows is intended to be a base for a readme or a man.
The access control to files is different in Linux and Windows. Both
situations rely on concepts of owner, group, administrator and world. In
Linux an owner and a group are defined for a file, and the rights to access
the file are defined for owner, group and world. 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).
Only data as defined for ntfs are used, so approximations have to be made to
make them available to the Linux world. As a consequence all security data
may be saved by standard Windows tools, whereas some security data is lost
when backing up by standard Linux tools.
In this proposal, ACL which grant or deny permissions to the owner, group and
world are used to build the Linux owner, group and world permissions as
returned to stat() and displayable by ls.
Similarly, when a file is chmod'ed, ACL are built according to rights granted
to user, group, world. Up to six ACL may be built to reflect 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 (the administrators are always granted all rights,
unless the owner is an administrator). There is a minimum of two ACL in
the situation where group has same rights as world and the owner is an
administrator with no less rights than world.
Inherited rights are overwritten during a chmod, however directories
keep their inheritance ability defined in Windows, and files created by
Windows in a subdirectory created by Linux in a directory by Windows
inherit access rights from this directory, even if different permissions
were defined for the subdirectory.
Initial access rights can be set in open(), and can be subsequenly changed
by chmod, chown or chgrp. Currently it is not possible to create a
read-only file.
Note : as in traditional ntfs-3g versions files are created with local
administrator both as owner and group, chmod cannot set specific rights to
group for such files. Owner and group remain the same until a chown or chgrp
is made. This does not apply to files created by Windows.
Currently the whole permission system is based on a mapping of Windows users
to Linux users, stored in a file named "mapping" located at the root of the
ntfs file system. If this file is missing, ntfs-3g acts as previously,
granting full access to all users.
The mapping file is organized in lines with three fields separated by
a semicolon, such as :
500:500:S-1-5-21-1833069642-4243175381-1340018762-1008
:500:S-1-5-21-1833069642-4243175381-1340018762-513
The first field is the uid of a Linux user to map, the second field
is the associated gid, and the third field is the corresponding
Windows user id (known as a sid). For user groups the first field
is left blank.
No explicit mapping is needed for standard groups, such as the
"All Users" group or "Administrator" group. If no user mapping is defined
for some file, it appears as owned by root, and depending on protections,
may be accessible to root only.
If 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 chmod.
No protection is currently set on the mapping file itself. It should obviously
be only accessible by an Administrator (implicitly mapped to root).
A small Windows utility (usermap.exe) has been developped to build this
mapping. It has to be run in command line mode. It just scan files in
"c:\Documents and Settings" and on the partition designated to be shared
among systems for file owners. For each of them it asks for the corresponding
Linux user or group. The resulting mapping file is written ready for use on
the designated partition. The source code of this utility is publicly
available under the GPL licence.
Unsolved problems
- creating a read-only file by open("name",O_CREAT,S_IREAD). This is
indicated in the fuse FAQ as being solved by a create method (not
implemented in ntfs-3g), with work-arounds which I do not understand.
- cacheing permissions, owner and group of a file. These are very
heavy to compute and should be kept in memory for further use.
- applying umask to created files. This should be an easy one. Apparently
it is not processed in mount options, nor is is available in fuse context.
Misc
- the security descriptor is always stored as an attribute (as in v1.x),
not in $Secure, thus keeping compatibility with NT4 at the expense of
storage. When changing permissions to a file, it would be possible to
store the new attributes where the old attributes were, but storing them
indiscriminately in $Secure would lose the compatility with old versions
(if useful, a mount option defining the required compatibility could be
used) [Note : the indexes defined for directories are perfectly adequate
for setting and retrieving the permissions].
Reactions wellcome
Enjoy
Jean-Pierre
--
JP André
email [EMAIL PROTECTED]
ntfs-3g.diff.tar.gz
Description: GNU Zip compressed data
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
