Attached are a few patches for evaluating the possible usage of ACL checking
in ntfs-3g. This is a first attempted to locate problems and trigger
reactions and is by no way to be used in real environments.

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 are used
to build the owner permissions, and ACL which grant or deny permissions to
anybody are used to build the world permissions. There is no checking of
rights granted to groups. These permissions are returned to stat() and
displayable by ls, but they are not used to check file access yet.

Similarly, when a file is chmod'ed, ACLs are built according to rights
granted to owner, world, and to administrators (the latter are always  
granted all rights). Inherited rights are lost after a chmod. Granting    
of rights is only done in chmod, and not in file or directory creation.

Only stat() and chmod() are implemented. File creation still defines
a standard owner and standard rights, and the owner defined for creation
is used to build the permissions in chmod().

A major key to this is the documentation on ntfs organization made
available by the ntfs projets, to which I am grateful.

My main concern about further developments on this path is about
performance. ACL data are not organized for easy use on Linux and a lot of
data has to be manipulated to make a basic check. Moreover, before making
virtually any operations on a file, checks have to be made on all the
directory levels in the path to the file. At least, Linux permissions     
should be kept in some cache to avoid recomputing them frequently.

Among the major things I have not (yet) solved, and for which I need some
help :

- defining a way to do the user mapping across OS's in dual-boot machines.
Storing the mapping is a point, defining a tool to administrate the mapping
is another (accessing the Windows register base to get friendly names
associated to Windows variants of uid and gid ?)

More technically (Szaka, can you help ?) :

- how, in the fuse context, can I know the uid of the user on behalf of whom
a request is being processed ?
- access to ACL's are normally made in an indexed file, which requires the
building of a hash key. Is the hash algorithm known ? is there available
code to walk in the index tree ?

If you have answers, please make them known. Anyway please feel free to
react.

Jean-Pierre

Attachment: /home/linux/rpmbuild/ntfs/ntfs-3g.dif.tgz
Description: GNU Zip compressed data

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel

Reply via email to