Hi, On 5 Sep 2007, Jean-Pierre Andre wrote:
> Here it is ! Very nice! This is a big topic which will need some time to go over and sort out all the hairy details but my quick first tests were very positive and the code is also nicely readable now. Congratulations! :-) > 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. Fantastic! :-) Would it be posible to port the tool to Linux? It would be highly valuable because people often don't have or want to use Windows (portable external disks, disk images) but they would still like to have some sort of user mapping. In the future, we could additionally use Samba's all kind of user name mapping services. Btw, Samba uses names (described at the "username map" section in 'man smb.conf') instead of uids, gids, and sids. However it's not know how we could get the Windows names from sids on Linux, but hopefully it's possible somehow. > 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. FUSE has a test utility named 'test' in its 'test' directory which includes quite many permission handling related tests. Just type 'make' in the 'test' dir to build it. There are other test suites you could use. If interested I'll send the details for you, or for anybody else. Some may need minor porting work to Linux but it would be extremely valuable for other file system projects as well. > The access control to files is different in Linux and Windows. I've saved a few related documents for you what unfortunately I can't find them right now. They talked mostly about how CIFS, Samba solves/handles the ACL mappings. One of them which may be useful: http://sambaxp.org/uploads/media/05-Andreas-Gruenbacher_-_Linux_Samba_and_ACLs.pdf > 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. tar supports acl's though, afaik, it was never investigated if it's enough to save NTFS ACLs fully. > 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, Ok. > unless the owner is an administrator). What do you mean exactly? Administrator should always have all rights, otherwise he can lock out himself. > 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. How is this possible, i.e. why does Windows ignore the permissions set by the directory created on Linux? That the lack of proper permission rights inheritance __is__ a real problem currently, what people keep reporting. It would be nice to solve this issue as well. > 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. I like this backward compatibility very much. It's important. However the driver didn't seem to work exactly the same. For instance the permissions of the newly created files were 0 (---------) and the driver syslogged 'User mapping built' even if there was no mapping file. Some initialization problem perhaps? > 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. I'll check this out, thanks. This wasn't an issue so far because of the lack of permission handling. The create method may also improve file creation performance by maximum two fold with the price of losing pre-2.6.15 kernel support unless we can find a workaround. But it should be feasible, I think. > - cacheing permissions, owner and group of a file. These are very > heavy to compute and should be kept in memory for further use. Unless performance is unusable slow and seriously sets back development or user deployment, the correctness is far more important in the early stages. Permission caching performance can be improved when it turns out that it's the bottleneck (the relevant fuse option is attr_timeout the default is one second, afair. For its document you need at least fuse 2.7.0 because earlier versions didn't document it). At the moment ntfs-3g has quite a lot of performance issues to be drastically improved in itself, in FUSE and on the kernel side. > - 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. It's processed during mount (goes to ctx->fmask and ctx->dmask) but the *mask mount options turn on default_permissions what we probably don't want. If FUSE or the kernel don't do the mode masking (and they indeed don't seem to pass it along) then this seems to be a bug unless I missed something which is also possible. > - 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]. Compatibility with NT4 is not an issue anymore, thankfully. There was only one support request for NT4 in the last five years but not for real use however for pure academic interest. At the moment the most important is correctness, backward compatibility, and usability. > Enjoy We do :-) Should we setup an ntfs-3g development branch in the CVS with commit right for you? Thanks Jean-Pierre! Szaka ------------------------------------------------------------------------- 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
