Hi Szaka,
Thank you for your reply, with very useful answers and
suggestions. Below, I have inserted a few remarks.
Jean-Pierre
Szabolcs Szakacsits wrote:
> 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! :-)
>
>
There were several problems which I have fixed. I
still have a strange one with access()
>> 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.
>
The main problem for porting the mapping tool to Linux is to
return the vol-id ("ctx->vol") to calling program, so that it
could then call entries in ntfs.so similar to GetFileSecurity()
and SetFileSecurity() from Win32, and bypassing fuse. I thought
of returning the vol-id in parameter f_fsid of statfs(). There
could be a second problem if vol-id points to data in an address
space private to ntfs-3g process and not usable in other
processes. If this should be confirmed, fuse cannot be bypassed.
> 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.
>
>
Getting Windows names is easy if system partition is mounted by
ntfs-3g : just read entries in "Documents and Settings". This is
basically what the tool I have developed does.
Supplying Linux names instead of uid and gid only implies
reading /etc/passwd and /etc/groups at mount time, with one
implementation if these files are over ntfs-3g, and a second
implementation if they are not (expecting them to have been
mounted).
I will also try to make a standard mapping for single-user systems,
getting uid and gid from mount arguments, and sid from the root
of the mounted file system.
There also are two complex situations :
- removable devices (such as USB keys) mounted on several
Windows and Linux systems.
- devices formatted and used on Linux with no Windows reference
>> 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
>
>
Fine, thanks
>> 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.
>
>
Well, if as root you type "chmod 000 foo" you expect foo to
be displayed as not accessible.... but of course if you are root
you bypass the non-accessibility. However there is no bypass
for Windows and the Windows administrator would have to
change permissions for accessing the file.
I thought this is better than seeing all files owned by root being
displayed as rwxrwx--- and unchangeable (so far I cannot
make a distinction between owner access and group access
for files owned by root).
>> 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?
>
Hum. With current development, doing a chmod (or chown)
on a directory defines a new base for inheritance.
However there is a flag called "inherit only" which can be
used to make grandchildren inherit rights which are not
granted to children. This is possible, but probably not
desirable.
> 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.
>
>
Well, doing chown or chmod is basically requesting to
override inheritance....
I think I should make inheritance the default behaviour
for people not wanting to define a user mapping, and in
this situation chmod and chown would be ineffective.
But ntfs-3g currently suppresses inheritance, so some
upgrade tool will be required.
>> 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.
>>
I should have added that owner and group are also
the same for files owned by root (until I find how
to make a distinction).
>> 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.
>
This implies loss of inheritance....
> 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?
>
Yes, there is an error in the logging. The messages for
success/failure have to be exchanged.
>
>
>> 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.
>
>
In your other message, you say you have implemented
the create method, I'll check if this is OK for creating
read-only files.
>> - 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.
>
>
I would also think of associating mode, uid and gid to
memory copies of mrec.
>> - 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.
>
>
OK
>> - 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.
>
OK. To be precise, partitions formatted for NT4 will
benefit from permission handling, but partitions
formatted for XP will not be usable by NT4.
> At the moment the most important is correctness, backward compatibility,
> and usability.
>
>
I agree.
>> Enjoy
>>
>
> We do :-)
>
> Should we setup an ntfs-3g development branch in the CVS with commit right
> for you?
>
Well, I am not familiar with cvs, and I do not know how
to get the best from it. But I will soon need an adequate
procedure for merging permission handling developments
with improvements and fixes for the standard version
until permission handling can be released. I also need to
make test versions available to people who volunteer for
tests.
Just make a proposal and I will follow (I have already tried
to setup an account on sourceforge (login jpandre).
> Thanks Jean-Pierre!
>
> Szaka
>
>
>
--
JP André
email [EMAIL PROTECTED]
-------------------------------------------------------------------------
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
