[This issue was posted earlier on ntfs-3g-devel at lists.sourceforge.net, I just copy-paste the initial conversation]

Hi again,

because the correct configuration of a UserMapping is rather complicated I ask, if it would be possible to allow the inherit option without permissions or any UserMapping.

I think, normal users just want, that new created, copied and moved files and folders just inherit the Windows permissions from their parent folder.
Is there any technical hurdle to establish this possibility?

Hi,


This is possible for the permissions, not for ownership.

Windows defines the owner of a file as the user who creates the file. When the file is created by Linux and no mapping is defined, Linux cannot set the correct owner, so the owner of the parent directory is used instead.
This lead to problems when the directory and the file should have different owners. For instance, the home directory of users is generally owned by root, so all files and directories created there will also be owned by root. In such situations some permissions related to owner will be wrong on Windows.

Try the attached patch "just-inherit.patch" with no user mapping file or "permissions" option, still with "inherit" option.

Regards

Jean-Pierre

Hi Jean-Pierre,

this patch is absolutely perfect, such as I was long time looking for and the origin reason, why I started looking deeper.
It should go into release and Linux distributors should be told to enable the inherit option by default. It's absolutely mandatory, that an object, located in a Windows user directory, should only be accessible from its own Windows user.


I cannot see any problem with this, but maybe you know better. A file, created directly in users home directory is (1) inadvisable, but (2) editable, re-nameable and deletable without problems as I tried after using your patch. Same for files and folders in E:\Public\ from all Windows users, this is really great.


The only disfigurement are the still duplicated superfluous permissions of folders:

Very much thanks for this,

Ulf

Correction:

I meant: Same for files and folders in *:\Users\Public\ ...

Thinking again, IMHO I think, the inherit behaviour should be default at all. If one explicitly wants the current behaviour, i.e.: any new created file has all permissions to anybody on Windows, it could be offered by an option like e.g. public, noinherit ....

Maybe the problems you mentioned occurred with Windows XP, but here on Window 7 there seems no problem to me.

See also: https://bugs.launchpad.net/ubuntu/+sour ... ug/1249674

Thanks,

Ulf

Hi,


It is great you got what you wanted.

I must have overlooked something. Can you be more precise about what you find non satisfactory ?

I will not support a change of behavior for standard mounting. There will be too many disoriented users.

When a buy an external disk, factory formatted as ntfs, and you create a file from Linux in the home directory, who do you consider as "its own Windows user" ?

Ubuntu may do this in its own right and face the consequences. I will not.

Regards

Jean-Pierre

As you can see in the screen shot there are 3 identities SYSTEM, Administratoren and Katrin which have permissions with full access, inherited from E:\Users\Katrin\. Additionally those 3 identities have special not inherited permissions. The latter are redundant, add no additional rights and therefore are superfluous. A folder, originally created from Windows in the same parent folder would not have those duplications. It would be more clean, if ntfs-3g would not add those redundant permissions when creating a new folder.

See my comment in https://bugs.launchpad.net/ubuntu/+sour ... ug/1249674.

Hmm, I'm not sure if I understand right, on an external disk, factory formatted as ntfs, there is no Windows user directory i.e. *:\Users\user\ so my statement would not apply there.

Hi,

Oh, I see. Actually they are not mergeable because they have different parameters.

However, this is not what I get on my computer, and I suspect this file was created with some different option or different patch. Try deleting the file and create it again.

Ok, if you have no requirements.

Regards

Jean-Pierre

I do not understand your opinion. The not inherited permissions are a subset of the inherited permissions. So IMHO the additional inherited permissions are redundant and therefore superfluous.

I tried again from scratch with new ntfs-3g 2014.2.15 + your just-inherit patch, no UserMapping and options default,inherit in the fstab. Same result I don't know, why you don't see the additional non-inherited permissions on a new created folder, not file.


I still have the requirement, if there is a Windows user directory i.e. *:\Users\user\, even on an external disk, and as consequence then there is a "its own Windows user".

Hi,


They may appear superfluous, but the inherited permissions may be changed on Windows through dynamic inheritance, and the non-inherited ones cannot. So they should not be merged.

Ok, this is because you did not also apply the "no-chmod.patch" and you created the file with some tool which changes the permissions (same issue as the gedit one). Please retry with the additional patch.

This is because you created the directory with another tool which does no chmod.

Regards

Jean-Pierre

When I am the creator of that folder and I just want solely inherited permissions, why should I worry about a theoretical scenario, as you describe, when I don't need and want it.

I do not know, which tool you mean. I was using nautilus to create new folders and also the new empty text files. To check, if there is something special with nautilus, I now created folders with "mkdir New_inherit", still without "no-chmod.patch". This results in same additional unwanted and therefore superfluous not-inherited permissions.

Yesterday I erroneously assigned users to katrin as primary group which deleted the Ubuntu defaults assignment to group katrin. With this, a new empty text file had the identical permissions as the edited result from gedit.

Hi, I now tested with both patches:
However, problem 1) does not occur in /media/Daten/Users/Public/ with just-interit+no-chmod.patch.

Hi again,

There may be another difference with yours and my computer.
The Windows accounts, which I tested with, were standard user accounts with restricted privileges.
Did you test on Windows account with administrative privileges?

Which is the correct order of the patches just-interit.patch and no-chmod.patch, because they change the same files?
Does it matter ?
I first executed just-interit.patch and then no-chmod.patch for my tests.

Hi,


I tried both, in Windows user home directories.

Is /media/Daten/Users/Katrin/ the home directory of Katrin on the Windows system partition ? or is it on another partition (not the Windows system one) ?

Can you retry, with both patches applied, to create a new directory on Linux, also a subdirectory of the newly created directory. Please do it twice, first with mkdir, then with Nautilus (this is to detect a situation where Nautilus creates the directory elsewhere and then renames it - unlikely, but I want to be sure) :

With mkdir, do

Similarly, with Nautilus, create /media/Daten/Users/Katrin/Nautilus and /media/Daten/Users/Katrin/Nautilus/Nautilus

Then please post the five secaudit outputs, so that I can retry with your settings :


The no-chmod patch was designed to be applied first, but the order should not matter.

Regards

Jean-Pierre

Yep, Katrin is not on system partition. I have:
C:\Users\Default\
C:\Users\Administrator\
E:\Users\Katrin\
E:\Users\Lasse\
E:\Users\Jakob\
I also tried with C:\Users\Administrator\. There I had the same effect with the additional superfluous not-inherited permissions.

With the info above, do you still need this test? I did some, but not so verbose, comparison yet but did not find any difference.
Does it matter, that I additionally have patched with acls.c.patch?

Hi,


Yes, please. I do not have a similar configuration. I am specifically worried about the lack in your base directory of a reference to its owner.

It does probably not matter, but I cannot be sure until I see the parent directory settings in the secaudit output.

Regards

Jean-Pierre

Here intermediately the results with additional acls.c.patch:

Thanks, Ulf

Hi,

Thank you for posting the secaudit outputs. I see that on the directory Katrin, there is an unusual flag "cannot be modified by inheritable ACEs" which does not exist on my computers (where the home directories are on the Windows system partition).

Something is apparently wrong in ntfs-3g as a consequence of this flag, and I have to design a test on Windows to determine the consequences of this flag in various conditions. This may take a few days, please be patient.

Regards

Jean-Pierre

Hey wow, the source of the problem is found now.
Thanks for your kind collaboration to make ntfs-3g again more compliant with Windows NTFS, at least for my private untypical configuration.

-Ulf

Maybe my attached registry scripts will help you to configure your system.
On Windows 7 first apply the registry script.
Then add a new user account.
Then log into the new user, this will automatically create the correct folder tree on the non-system partition.
On Windows XP, the procedure is a little more complicated, but my registry script may give you some hint.

Do you yet have some explanation about the non-accessible folders on the Public path i.e. E:\Users\Public ?

Hi,

Attached are two patches which may be of interest to you :

The first one (double-inheritance.patch) aims at solving the superflous ACE you got. Unfortunately this condition falls in a gray zone : According to MSDN in http://msdn.microsoft.com/en-us/library/windows/desktop/aa374924(v=vs.85).aspx "This occurs if the inheritable ACE contains generic information", but I have not been able to determine what is meant by "contains generic information", so I can only propose heuristics checked valid on home directories of Windows XP, Vista, Windows 7 and Windows 8.

The second patch (better-owner.patch) aims at improving the heuristics for setting an owner when the owner cannot be defined in the normal way (typically a user not mapped).

Regards

Jean-Pierre

Hi,

are these patches meant on top of the just made patches or from scratch?
Are the new patches independent from each other?

Anyway, much thanks, Ulf