FAQ SearchLogin
Tuxera Home
View unanswered posts | View active topics It is currently Wed Nov 25, 2020 10:53



Post new topic Reply to topic  [ 71 posts ]  Go to page Previous  1, 2, 3  Next
Inherit privileges from parent folder for new created files 
Author Message
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Inherit privileges from parent folder for new created files
Hi,

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

They are independent. They try to solve different issues you may have, and you may drop the ones which are not satisfactory or not useful to you. As far as I can tell you can apply them in any order.

Regards

Jean-Pierre


Wed Apr 16, 2014 18:39
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Hi, here are my results:

I added all Linux users to a new group "windows7" as indicator for "assigned with this single Windows 7 entity", and changed the UserMapping:
Code:
:windows7:S-1-5-21-2869643010-2844629126-3994450086-513
jakob:jakob:S-1-5-21-2869643010-2844629126-3994450086-1005
lasse:lasse:S-1-5-21-2869643010-2844629126-3994450086-1006
katrin:katrin:S-1-5-21-2869643010-2844629126-3994450086-1007

jpa wrote:
The first one (double-inheritance.patch) aims at solving the superflous ACE you got.
The result of this patch - on top of the 3 others - looks really great. Except the now omitted superfluous ACEs, I see another little change, which seems to allow access for all users to the \Users\Public\ folder, which seems sufficient and correct to me:
Attachment:
diff of double-inherited.png
diff of double-inherited.png [ 106.06 KiB | Viewed 49513 times ]


Quote:
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).
Wow, it's really great to see, that now all files and folders in \Users\Katrin\ are owned by Katrin, even if there was no UserMapping 8)

But in \Users\Public\ folder in case of no UserMapping it replaces the owner from Administrators to Administrator and accordingly changes the assignment of the 2nd "special" ACE. I'm not sure, if this is the right way in the case of Administrator account, because if I add a new folder with Windows Explorer from Administrator at the same place, it becomes also owned by Administrators, and additionally the 2nd "special" ACE is absent, which seems consequent as redundant:
Attachment:
diff of better-owner.png
diff of better-owner.png [ 243.21 KiB | Viewed 49513 times ]

Additionally I observe a little difference on the sources of inherited permissions - higher-level Object vs. E:\Users\Public\. This may be not important, but may be again more compliant with Windows.

Regards,
Ulf


Fri Apr 18, 2014 16:11
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
There are 2 other little problems:
If I have trash folders on NTFS partitions, e.g. .Trash-1000, this folder is accessible from any Linux user. If I try to zero the permissions with nautilus, they automatically appear again. I think, the trash folder of User A should not be accessible from user B. Any idea, how to manage that?

I think it would be nice if trash folders and .NTFS-3G were automatically flagged as system and hidden from Windows view.


Fri Apr 18, 2014 23:40
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Correction:
If I try to zero the permissions for world with nautilus, ...


Sat Apr 19, 2014 00:04
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Inherit privileges from parent folder for new created files
Hi,

Quote:
If I have trash folders on NTFS partitions, e.g. .Trash-1000, this folder is accessible from any Linux user. If I try to zero the permissions with nautilus, they automatically appear again.

Quote:
Correction:
If I try to zero the permissions for world with nautilus, ...

You are discovering the drawbacks of inheritance : when using "inherit", the permissions set on a file or directory are defined by the parent directory and you cannot change them from Linux. This is what the patch "no-chmod" was for, in order to prevent editors like gedit from applying Linux rules to permissions on a file.
Quote:
I think, the trash folder of User A should not be accessible from user B. Any idea, how to manage that?

The permissions on the trash directory are defined by Windows inheritance from the root of the file system. However I would expect Nautilus to move trashed files to the trashed directory, preserving the initial ownership and permissions.
As a workaround, you may try to create trash directories in home directories of each user, and then move these new trash directories to their expected location, thus keeping their original ownership and permissions.
Quote:
I think it would be nice if trash folders and .NTFS-3G were automatically flagged as system and hidden from Windows view.

The mount option "hide_dot_files" is for marking as hidden (from Windows users) the files and directories whose initial is a dot. The option takes effect at file or directory creation, so you have to delete and recreate the said directories. Marking them as system may have adverse consequences.

Also, can you please post the secaudit output for your \Users\Public, I am not sure your settings are the same as mine.

Regards

Jean-Pierre


Sat Apr 19, 2014 10:15
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Attachment:
Secaudit Public.zip [1.56 KiB]
Downloaded 1150 times


Sat Apr 19, 2014 20:51
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Hi again,

I upgraded Ubuntu from 13.10 to 14.04 and my fstab was changed from
Code:
UUID= /media/Windows7 ntfs defaults,inherit,noauto 0 0
UUID= /media/Daten ntfs defaults,inherit 0 0
to
Code:
UUID= /media/Windows7 ntfs defaults,umask=007,gid=46 0 0
UUID= /media/Daten ntfs defaults,umask=007,gid=46 0 0
Now I have changed it to:
Code:
UUID= /media/Windows7 ntfs defaults,umask=007,gid=46,inherit,noauto 0 0
UUID= /media/Daten ntfs defaults,umask=007,gid=46,inherit 0 0
Does that make sense, as I think, inherit overrides the umask and gid settings?


jpa wrote:
You are discovering the drawbacks of inheritance : when using "inherit", the permissions set on a file or directory are defined by the parent directory and you cannot change them from Linux. This is what the patch "no-chmod" was for, in order to prevent editors like gedit from applying Linux rules to permissions on a file.
So if I understand correct, no-chmod.patch completely blocks changing the permissions from Linux side, even with chmod command from terminal. Because there is no "inherit concept" in Linux, Linux can't inherit anything from a container.
Thinking about gedit: Do you think, it could be a solution, when gedit creates a new file for the changes in order to save the original version with *~, it would compare the permissions of both files, and only set the permissions again, if they differ.
But I also tried to copy files and folders with nautilus and equally resulted with not-inherited permissions from Ubuntu view. With Windows, e.g. a copied folder has full access from Katrin =OK, full access except deleting sub-folders and files from Administrators =?? and only permissions and attributes read access from others =OK.
Do you have any influence with ntfs-3g on the copy execution, so that the copy will have the same inherited permissions instead copied non-inherited ones?
Attachment:
Secaudit Katrin-New_inherit copy.zip [2.14 KiB]
Downloaded 1179 times


Quote:
The permissions on the trash directory are defined by Windows inheritance from the root of the file system. However I would expect Nautilus to move trashed files to the trashed directory, preserving the initial ownership and permissions.
As a workaround, you may try to create trash directories in home directories of each user, and then move these new trash directories to their expected location, thus keeping their original ownership and permissions.
I did 4 experiments:
1) With Windows I added non-inherited permissions to disallow "change" for authenticated users and "read, execute" for normal users.
Result with Windows: C:\.Trash-0 is fully accessible from Administrators =OK, but Administrator and SYSTEM can only delete sub-folders and files and read+change permissions and ownership =DOES NOT LOOK GOOD.
Result with Ubuntu: d-w--w--w- What does that mean? Is that a valid setting?
2) With Ubuntu I changed permissions of .Trash-1000 from drwxrwxrwx to drwx------.
Result with Ubuntu: .Trash-1000 is only accessible from katrin =OK.
Result with Windows: C:\.Trash-1000 has full access from Katrin =OK, full access except deleting sub-folders and files from Administrators =?? and only permissions and attributes read access from others =OK.
3) With Ubuntu I changed permissions of .Trash-1001 from drwxrwxrwx to drwxrwx---.
Result with Ubuntu: .Trash-1001 is only accessible from jakob =OK.
Result with Windows: C:\.Trash-1001 has full access from Jakob =OK, full access except deleting sub-folders and files from Administrators =?? and only permissions and attributes read access from others =OK.
4) With Windows I moved .Trash-1002 to E:\Users\Lasse\, set the permissions to inherit from C:\Users\Lasse\, again unset to inherit with saving them as not-inherited and moved it back to E:\
With Windows I manually changed permissions of .Trash-1002 to full access from Administrators, SYSTEM and Lasse.
Result with Windows: =OK.
Result with Ubuntu: drwx------ =OK.

I'm really wondering, that from 2) and 3) the permissions look identical from Windows view, even they are different from Ubuntus view. Any explanation?
Attachment:
Secaudit Trash.zip [2.78 KiB]
Downloaded 1122 times


Quote:
The mount option "hide_dot_files" is for marking as hidden (from Windows users) the files and directories whose initial is a dot.
Much thanks for the hint.

Quote:
Marking them as system may have adverse consequences.
The combination of hidden+system flag is interesting, because since Windows 7 one can set Windows Explorer allowing to display hidden, but not system files.
I remember you wrote, that deletion of a folder could be prohibited with the sticky bit. As a fairly free idea: Maybe the sticky bit could be mapped to the system flag, which would prevent from unauthorized deletion of such folder from both sides.


Sun Apr 20, 2014 20:31
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Hi again,
UlfZibis wrote:
But I also tried to copy files and folders with nautilus and equally resulted with not-inherited permissions from Ubuntu view. With Windows, e.g. a copied folder has full access from Katrin =OK, full access except deleting sub-folders and files from Administrators =?? and only permissions and attributes read access from others =OK.
Do you have any influence with ntfs-3g on the copy execution, so that the copy will have the same inherited permissions instead copied non-inherited ones?
Attachment:
Secaudit Katrin-New_inherit copy.zip

Oops, I missed to look closer to the results from cp with terminal, it seems, it does the right thing. So I'm afraid, that there are many applications which do the "wrong" thing on NTFS, puuuhh :evil:
What you think?


Sun Apr 20, 2014 21:16
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Inherit privileges from parent folder for new created files
Hi,

Quote:
But in \Users\Public\ folder in case of no UserMapping it replaces the owner from Administrators to Administrator and accordingly changes the assignment of the 2nd "special" ACE. I'm not sure, if this is the right way in the case of Administrator account,

This is because Windows makes a distinction between a generic Administrator which has full rights but no account, and a local Administrator which has an account which has most rights and to which you can log in. On the contrary, Linux usually has a single account named root to which you can log in. Improving this implies creating several administration accounts on Linux (and updating /etc/sudoers for "sudo") .
Quote:
Does that make sense, as I think, inherit overrides the umask and gid settings?

inherit does not override the umask and gid, but having a user mapping does. Also I thought you wanted hide_dot_files.
Quote:
So if I understand correct, no-chmod.patch completely blocks changing the permissions from Linux side, even with chmod command from terminal. Because there is no "inherit concept" in Linux, Linux can't inherit anything from a container.

no-chmod.patch blocks changing the permissions because you wanted it that way to avoid problems with gedit. This is unrelated to a lack of "inherit concept" in Linux.
Quote:
Thinking about gedit: Do you think, it could be a solution, when gedit creates a new file for the changes in order to save the original version with *~, it would compare the permissions of both files, and only set the permissions again, if they differ.

No idea. gedit expect Linux rules, if you want gedit to apply Windows rules on Linux, you have to ask people who know about gedit.
Quote:
Do you have any influence with ntfs-3g on the copy execution, so that the copy will have the same inherited permissions instead copied non-inherited ones?

File systems do not know what a copy is. They know about creating a file (which did not exist), writing to a file (which was created previously) and moving a file within the same partition.

With inherit, inheritance is applied when creating a file, no permission is changed when writing to a file, and the original permissions are kept when moving a file.
Quote:
Quote:
The permissions on the trash directory are defined by Windows inheritance from the root of the file system. However I would expect Nautilus to move trashed files to the trashed directory, preserving the initial ownership and permissions.
As a workaround, you may try to create trash directories in home directories of each user, and then move these new trash directories to their expected location, thus keeping their original ownership and permissions.

I did 4 experiments:

But these experiments excluded what I told you.
Quote:
1) With Windows I added non-inherited permissions to disallow "change" for authenticated users and "read, execute" for normal users.
Result with Windows: C:\.Trash-0 is fully accessible from Administrators =OK, but Administrator and SYSTEM can only delete sub-folders and files and read+change permissions and ownership =DOES NOT LOOK GOOD.
Result with Ubuntu: d-w--w--w- What does that mean? Is that a valid setting?
2) With Ubuntu I changed permissions of .Trash-1000 from drwxrwxrwx to drwx------.
Result with Ubuntu: .Trash-1000 is only accessible from katrin =OK.
Result with Windows: C:\.Trash-1000 has full access from Katrin =OK, full access except deleting sub-folders and files from Administrators =?? and only permissions and attributes read access from others =OK.
3) With Ubuntu I changed permissions of .Trash-1001 from drwxrwxrwx to drwxrwx---.
Result with Ubuntu: .Trash-1001 is only accessible from jakob =OK.
Result with Windows: C:\.Trash-1001 has full access from Jakob =OK, full access except deleting sub-folders and files from Administrators =?? and only permissions and attributes read access from others =OK.
4) With Windows I moved .Trash-1002 to E:\Users\Lasse\, set the permissions to inherit from C:\Users\Lasse\, again unset to inherit with saving them as not-inherited and moved it back to E:\
With Windows I manually changed permissions of .Trash-1002 to full access from Administrators, SYSTEM and Lasse.
Result with Windows: =OK.
Result with Ubuntu: drwx------ =OK.

I'm really wondering, that from 2) and 3) the permissions look identical from Windows view, even they are different from Ubuntus view. Any explanation?

The experiments lead to nowhere because Windows and Linux do not work the same way. Windows has eleven bits to describe user permissions, whereas Linux has only three. Mapping eleven bits to three bits can only have defects. If you inherit from non-standard patterns you get non-standard results.
Quote:
The combination of hidden+system flag is interesting, because since Windows 7 one can set Windows Explorer allowing to display hidden, but not system files.

But the system flag is used for implementing concepts which are unknown to Windows : pipes, sockets, symlinks, etc.
Quote:
I remember you wrote, that deletion of a folder could be prohibited with the sticky bit. As a fairly free idea: Maybe the sticky bit could be mapped to the system flag, which would prevent from unauthorized deletion of such folder from both sides.

No. The sticky bit of a directory prevents users from deleting files they do not own in the directory. The Windows non-delete flag has to be set on individual files not on the parent directory. You cannot emulate multiple individual flags in a single parent flag.

Now it is time for summarizing.

I designed five patches for you :

- acls.c.patch for giving full visibility to /Users/Public, based on defining Linux users as interactive users.
- no-chmod.patch for preventing Linux programs from changing permissions on NTFS files.
- inherit-only.patch for allowing Windows-type inheritance even if no user mapping is defined.
- better-owner.patch for improving the heuristics which define an owner of a home directory (which has no owner recorded)
- double-inheritance.patch for fixing a bug in the Windows inheritance implementation when the flag "cannot be modified by inheritable ACEs" is set.

Are these proposals useful ?

Regards

Jean-Pierre


Mon Apr 21, 2014 16:32
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Hi Jean-Pierre,

sorry for the delay.

jpa wrote:
Quote:
But in \Users\Public\ folder in case of no UserMapping it replaces the owner from Administrators to Administrator and accordingly changes the assignment of the 2nd "special" ACE. I'm not sure, if this is the right way in the case of Administrator account,
This is because Windows makes a distinction between a generic Administrator which has full rights but no account, and a local Administrator which has an account which has most rights and to which you can log in. On the contrary, Linux usually has a single account named root to which you can log in. Improving this implies creating several administration accounts on Linux (and updating /etc/sudoers for "sudo") .
Yes I know all that, but isn't it possible for ntfs-3g to drop the superfluous Administrator ACE and set the owner to Administrators in such special case, as it is done by Windows if a new folder is added with Windows Explorer from Administrator at the same place?

Quote:
Also I thought you wanted hide_dot_files.
Yes, I didn't had set it yet, but now it is set.

Quote:
... and the original permissions are kept when moving a file.
On Windows, when a file, which inherits permissions from it's parent folder, is moved, it after inherits the permissions from the destination folder which may differ from the original, so in result the permissions are NOT kept. How does ntfs-3g deal with that? I think it would be reasonable to follow the Windows behavior.

Quote:
But these experiments excluded what I told you.
I think, experiment 4 is basically the same as you told, but keeps the content and the inner file structure of the existing trash folder. BTW, both methods only work, if they are done within the same volume. E.g. moving the prepared trash folder from C:\Users\Administrator back to E:\ replaces the permissions by inheritance from E:\ :-( , so I had to manually set them correctly.
I additionally must mention, that there was a typo in the experiment 4 description, and a line was erroneously left from copy n' paste. Here is the correct description:
Quote:
4) With Windows I moved .Trash-1002 to E:\Users\Lasse\, set the permissions to inherit from E:\Users\Lasse\, again unset to inherit with saving them as not-inherited and moved it back to E:\.
Result with Windows: =OK.
Result with Ubuntu: drwx------ =OK.

Quote:
The experiments lead to nowhere because Windows and Linux do not work the same way. Windows has eleven bits to describe user permissions, whereas Linux has only three. Mapping eleven bits to three bits can only have defects. If you inherit from non-standard patterns you get non-standard results.
I listed these experiments just for your info and having in mind, that you could benefit from reviewing the current mapping heuristics. Especially the comparison of 2) and 3) makes me wonder why the results from Linux view differ even if I see no difference with Windows Explorer view. I believe there must be a difference, examining the secaudit logs, which I'm not able to read in detail.

Quote:
No. The sticky bit of a directory prevents users from deleting files they do not own in the directory. The Windows non-delete flag has to be set on individual files not on the parent directory. You cannot emulate multiple individual flags in a single parent flag.
So theoretically it would be possible to set the sticky bit in .NTFS-3G to prevent others than root/Adminstrators from deleting the UserMapping file ...just a thought.

Quote:
Now it is time for summarizing.
Yep!

- acls.c.patch for giving full visibility to /Users/Public, based on defining Linux users as interactive users.
- inherit-only.patch for allowing Windows-type inheritance even if no user mapping is defined.
- better-owner.patch for improving the heuristics which define an owner of a home directory (which has no owner recorded)
- double-inheritance.patch for fixing a bug in the Windows inheritance implementation when the flag "cannot be modified by inheritable ACEs" is set.

These 4 patches to me seem ready to include in next ntfs-3g release. They work as expected.
But there remains a little flaw about a little difference on the sources of inherited permissions - higher-level Object vs. E:\Users\Public\ as I described here in the last line. This may be not important, but may be again more compliant with Windows. You asked me the secaudit log of E:\Users\Public\ for that. Did you find any explanation for that little difference?

- no-chmod.patch for preventing Linux programs from changing permissions on NTFS files.

This patch has pros and cons:
pro:
Files are prevented from unwanted non-inherited permissions by applications e.g. upon changes from gedit or copy from nautilus.
Permissions are completely under control of NTFS inheritance which may mostly be the most secure solution.
contra:
chmod is blocked always from Linux side.

Maybe you could alter the no-chmod.patch as follows:
If there is a chmod request, it could check if the current permission interpretation from ntfs-3g is equivalent with the requested chmod pattern and if yes do nothing. I'm not sure, if a file creation request could contain a permission definition. If yes, then ntfs-3g could absorb it if the result would be equivalent without it.

Otherwise, this option could be only provided upon an additional mount option.

Regards

Ulf


Wed Apr 23, 2014 01:16
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Inherit privileges from parent folder for new created files
Hi,

Quote:
Yes I know all that, but isn't it possible for ntfs-3g to drop the superfluous Administrator ACE and set the owner to Administrators in such special case, as it is done by Windows if a new folder is added with Windows Explorer from Administrator at the same place?

I have tried to improve the "double-inheritance" scheme, please try.
Quote:
On Windows, when a file, which inherits permissions from it's parent folder, is moved, it after inherits the permissions from the destination folder which may differ from the original, so in result the permissions are NOT kept. How does ntfs-3g deal with that? I think it would be reasonable to follow the Windows behavior.

It does. The behavior on Windows is the same as on Linux.
Quote:
E.g. moving the prepared trash folder from C:\Users\Administrator back to E:\ replaces the permissions by inheritance from E:\ :-( , so I had to manually set them correctly.

Hey! This is NOT a file move, the destination is not on the same partition and a new file has to be created. This is a copy and delete.
Quote:
4) With Windows I moved .Trash-1002 to E:\Users\Lasse\, set the permissions to inherit from E:\Users\Lasse\, again unset to inherit with saving them as not-inherited and moved it back to E:\.

This is not what I wanted you to do. Rather, please create a NEW E:\Users\Lasse\.Trash-1002, then move (a real move, not a copy) to E:\.Trash-1002. I am assuming that Lasse has uid 1002, and the trash folder is expected in the root of the file system.
Quote:
So theoretically it would be possible to set the sticky bit in .NTFS-3G to prevent others than root/Adminstrators from deleting the UserMapping file ...just a thought.

No benefit, as root always has all rights. The usual way is to set permissions of .NTFS-3G as 0555 to prevent normal users from inserting or deleting files within this directory.
Quote:
But there remains a little flaw about a little difference on the sources of inherited permissions - higher-level Object vs. E:\Users\Public\ as I described here in the last line. This may be not important, but may be again more compliant with Windows. You asked me the secaudit log of E:\Users\Public\ for that. Did you find any explanation for that little difference?

This is a difficult case because E:\Users\Public contains an owner reference which defeats the heuristics. On my computer I do not have that, was your Public folder created by an ordinary user ? The new double-inheritance should also improve this.
Quote:
Otherwise, this option could be only provided upon an additional mount option.

You would have to mount temporarily with this option to temporarily allow a chmod in a special situation, and you already have this possibility by temporarily removing the inherit option.

Note : the new-double-inheritance patch replaces the old one, do not apply both.

Regards

Jean-Pierre


Attachments:
new-double-inheritance.patch.gz [1.06 KiB]
Downloaded 1162 times
Wed Apr 23, 2014 12:28
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
jpa wrote:
Quote:
Yes I know all that, but isn't it possible for ntfs-3g to drop the superfluous Administrator ACE and set the owner to Administrators in such special case, as it is done by Windows if a new folder is added with Windows Explorer from Administrator at the same place?
I have tried to improve the "double-inheritance" scheme, please try.
It didn't help against the superfluous Administrator ACE and didn't set the owner to Administrators when there is no UserMapping, but it helped in 3 of 4 cases to change the inheritance from higher-level Object to E:\Users\Public\ and with UserMapping the inheritance sources were completely identical as if folder creation happened from Windows, VERY GOOD!
Attachment:
diff of new-double-inherited.png
diff of new-double-inherited.png [ 180.45 KiB | Viewed 49476 times ]


Quote:
Quote:
On Windows, when a file, which inherits permissions from it's parent folder, is moved, it after inherits the permissions from the destination folder which may differ from the original, so in result the permissions are NOT kept. How does ntfs-3g deal with that? I think it would be reasonable to follow the Windows behavior.
It does. The behavior on Windows is the same as on Linux.
I had different experience using new-double-inheritence with UserMapping. In one case the permissions were not inherited and in the other case they look very different from Windows Move.:
Attachment:
Move_inherited.png
Move_inherited.png [ 163.7 KiB | Viewed 49476 times ]


Quote:
Hey! This is NOT a file move, the destination is not on the same partition and a new file has to be created. This is a copy and delete.
I just wanted to mention that your instruction doesn't work here for cases for configuring the right permissions for the trash folders if the home dir to use is on a different volume.

Quote:
Quote:
4) With Windows I moved .Trash-1002 to E:\Users\Lasse\, set the permissions to inherit from E:\Users\Lasse\, again unset to inherit with saving them as not-inherited and moved it back to E:\.
This is not what I wanted you to do. Rather, please create a NEW E:\Users\Lasse\.Trash-1002, then move (a real move, not a copy) to E:\.Trash-1002.
I don't understand why you resist on that, because a moved and then prepared folder as described has the same permissions as a new folder in E:\Users\Lasse, but permits to keep the yet existing content.

Quote:
Quote:
So theoretically it would be possible to set the sticky bit in .NTFS-3G to prevent others than root/Adminstrators from deleting the UserMapping file ...just a thought.
No benefit, as root always has all rights.
Yes, but others don't have all rights to delete the UserMapping.
Quote:
The usual way is to set permissions of .NTFS-3G as 0555 to prevent normal users from inserting or deleting files within this directory.
Here I have 0700. It works and root/Administrators have the rights for change. Maybe it's because from fstab the partitions are mounted from root. So I may I should set to 0755 if I want to mount from normal user with fstab option "user".

Quote:
Quote:
But there remains a little flaw about a little difference on the sources of inherited permissions - higher-level Object vs. E:\Users\Public\ as I described here in the last line. This may be not important, but may be again more compliant with Windows. You asked me the secaudit log of E:\Users\Public\ for that. Did you find any explanation for that little difference?
This is a difficult case because E:\Users\Public contains an owner reference which defeats the heuristics. On my computer I do not have that, was your Public folder created by an ordinary user ?
I created the Public folder with repair console from Windows Install DVD by:
Code:
xcopy /C /H /K /O /X /B C:\Users F:\Users
xcopy /E /C /H /K /O /X /B C:\Users\Public F:\Users\Public
xcopy /E /C /H /K /O /X /B "C:\ProgramData\Microsoft\Windows NT" "F:\Users\Public\AppData\Roaming\Microsoft\Windows NT"
del /P /F /S "C:\ProgramData\Microsoft\Windows NT"
After I set following junctions using Link Shell Extension (great tool!):
C:\Users\All Users\Desktop, Documents, Favorites >-> E:\Users\Public
C:\Users\All Users\Local, Roaming >-> E:\Users\Public\AppData
C:\Users\All Users\Microsoft\Windows NT >-> E:\Users\Public\AppData\Roaming\Microsoft
After I executed ProfileList_E_W7.reg and then added Katrin, Jakob, Lasse.

Quote:
Quote:
Otherwise, this option could be only provided upon an additional mount option.
You would have to mount temporarily with this option to temporarily allow a chmod in a special situation,
Yes, this sounds not very comfortable, user would be free to allow chmod, and in case of determining it by fstab the responsibility would be on the system maintainer.
Quote:
and you already have this possibility by temporarily removing the inherit option.
Hm, but then all inheritance, even on new created files is lost.

Hopefully you could implement my more comfortable suggestion.

Much thanks,

Ulf


Thu Apr 24, 2014 03:24
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Inherit privileges from parent folder for new created files
Hi,

Quote:
I created the Public folder with repair console from Windows Install DVD by:

This explains why the permissions in your /Users/* directories are not the usual ones. You may want to know there is a simple way to make an exact copy of ownership and permissions, even across partition boundaries on http://www.tuxera.com/community/ntfs-3g ... /#ntfsacls

I have kept a record of the behaviors which are still not quite satisfactory to you, in case I have a better proposal later.

Also a bug related to ACLs has been found recently. It may cause problems after chkdsk has deleted ACLs which are not used any more. Some of the ACLs which you have created in your tests are probably not used by any files now, so chkdsk will reclaim the space and you might be eligible for the bug. Please apply the patch below before running chkdsk.

Regards

Jean-Pierre


Attachments:
deleted-acl.patch.gz [1.68 KiB]
Downloaded 1159 times
Sat Apr 26, 2014 09:07
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Hi,

jpa wrote:
Quote:
I created the Public folder with repair console from Windows Install DVD by:

This explains why the permissions in your /Users/* directories are not the usual ones. You may want to know there is a simple way to make an exact copy of ownership and permissions, even across partition boundaries on http://www.tuxera.com/community/ntfs-3g ... /#ntfsacls
Much thanks for the link.
But I'm afraid, I can not use it anymore, because I have deleted the original C:\Users\Public.
Why do you think, xcopy /E /C /H /K /O /X /B doesn't copy the ACLs correctly?

Quote:
Also a bug related to ACLs has been found recently. It may cause problems after chkdsk has deleted ACLs which are not used any more. Some of the ACLs which you have created in your tests are probably not used by any files now, so chkdsk will reclaim the space and you might be eligible for the bug. Please apply the patch below before running chkdsk.
I do not understand. How can a patch on Linux ntfs-3g have influence when running chkdsk with Windows?

Thanks, Ulf


Mon Apr 28, 2014 01:23
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Inherit privileges from parent folder for new created files
Hi,

Quote:
Why do you think, xcopy /E /C /H /K /O /X /B doesn't copy the ACLs correctly?

I am not blaming that line specifically, but in your resulting /Users/Public there is an ACE giving full permissions to the general administrator (S-1-5-21-2869643010-2844629126-3994450086-500), which I do not see in standard installations of Vista, Windows 7 or Windows 8. As a consequence you get some confusion between Administrator and Administrators (both mapped to Linux root).
Quote:
How can a patch on Linux ntfs-3g have influence when running chkdsk with Windows?

The patch has obviously no effect on chkdsk, it has an effect on ntfs-3g the first time it creates an ACL after chkdsk has deleted the last one.

Regards

Jean-Pierre


Mon Apr 28, 2014 10:13
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
jpa wrote:
I am not blaming that line specifically, but in your resulting /Users/Public there is an ACE giving full permissions to the general administrator (S-1-5-21-2869643010-2844629126-3994450086-500), which I do not see in standard installations of Vista, Windows 7 or Windows 8. As a consequence you get some confusion between Administrator and Administrators (both mapped to Linux root).
After the xcopy, I compared the original C:\Users\Public with the copy visually with Explorers properties tool, and didn't see a difference, so the blamed additional ACE should have been there before and I suspect why your copy method could do anything better. Could you please show a screen shot here of your /Users/Public. I guess, it would be save to delete all additional ACEs on my system.

On my system I have un-hidden the Administator on Windows graphical login dialogue to allow all other accounts to have no administrative rights. Maybe while logging in to Administrator, and doing something automatically adds that ACE to C:\Users\Public.

Quote:
The patch has obviously no effect on chkdsk, it has an effect on ntfs-3g the first time it creates an ACL after chkdsk has deleted the last one.
OK, thanks, so I will patch all my experimental ntfs-3g builds before further use.


Mon Apr 28, 2014 11:08
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Inherit privileges from parent folder for new created files
Hi,

Quote:
Could you please show a screen shot here of your /Users/Public. I guess, it would be save to delete all additional ACEs on my system.

Attached is a command to make an ACL copy of my factory-set Users/Public from Windows 7 onto some directory. This is a long command which this forum cannot display correctly. Just change the directory designated at the end of command, and copy it to a Linux terminal for execution. Better designate a temporary directory and compare with your settings.

Regards

Jean-Pierre


Attachments:
setpublic.sh.gz [190 Bytes]
Downloaded 1145 times
Mon Apr 28, 2014 21:37
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Hi Jean-Pierre
jpa wrote:
Attached is a command to make an ACL copy of my factory-set Users/Public from Windows 7 onto some directory. This is a long command which this forum cannot display correctly. Just change the directory designated at the end of command, and copy it to a Linux terminal for execution. Better designate a temporary directory and compare with your settings.

Now I've tried your command:
Attachment:
diff of Public-Public_tmp.png
diff of Public-Public_tmp.png [ 84.55 KiB | Viewed 49384 times ]
The only difference I can see, that you have full access rights to anybody instead only Administrators and Administrator.
Having full access to anybody means:
- All other permissions are redundant and therefore superfluous.
- Even Guests and all other Computers via network have full access.
This makes me wonder. Why the fidgeting with INTERACTIVE if anybody has full access?
Maybe the full access to anybody is result of your configuration, which is not anymore factory-set. I remember that I experienced, folders become accessible to anybody as consequence of configuring the Windows home network.


Sun May 04, 2014 17:01
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Hi again,
I now have decided to add the no-chmod patch to my friends computer, as I think it's more save to block chmod than to corrupt Windows inheritance with the culprit, intentional change of permissions is not possible. Have you tried my suggestion on filtering chmod upon it does not effectively change the permissions view from Linux?

Regarding the 1st screenshot on viewtopic.php?p=38308&sid=83ff666c18c833dc7bd8845f436236a2#p38308:
Have you tried to find a solution how to suppress the additional Administrator(s) ACE which is not there if a new folder is created from Windows Explorer?
Have you tried to find a solution upon the different inheritance from - higher-level Object vs. E:\Users\Public\ - with ntfs-3g in contrary with Windows behaviour?

Regarding the 2nd screenshot:
Have you tried to find a solution upon the different behavior of ntfs-3g when moving a folder to a different location with different rights to inherit?

Additional note on /Users/Public/
Is think it would be resonable in my case to delete the full access ACE of Administrator, as Administrators still have full access. What you think?


Sun May 04, 2014 17:39
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Inherit privileges from parent folder for new created files
Hi,

Quote:
Having full access to anybody means:
- All other permissions are redundant and therefore superfluous.
- Even Guests and all other Computers via network have full access.
This makes me wonder. Why the fidgeting with INTERACTIVE if anybody has full access?
Maybe the full access to anybody is result of your configuration, which is not anymore factory-set.

I am sure this is the factory configuration, as I had taken an image of the file system before doing anything else. You can delete this ACE if this does not match your needs, I will just get a different behavior.
Quote:
Have you tried my suggestion on filtering chmod upon it does not effectively change the permissions view from Linux?

No, because there will be situations where chmod changes the permissions in a non-inheritable way, and users will get different behaviors depending on obscure conditions.
Quote:
Have you tried to find a solution how to suppress the additional Administrator(s) ACE which is not there if a new folder is created from Windows Explorer?

ntfs-3g is a file system, it will not emulate Windows Explorer.
Quote:
Have you tried to find a solution upon the different inheritance from - higher-level Object vs. E:\Users\Public\ - with ntfs-3g in contrary with Windows behaviour?

Please post again the secaudit output for the parent directory, the inner directory created by the Windows mkdir command, and the one created by the Linux mkdir command. Avoid using applications which may impose their own view on permissions.
Quote:
Have you tried to find a solution upon the different behavior of ntfs-3g when moving a folder to a different location with different rights to inherit?

Moving a file or directory within a file system does not change the permissions. A file or directory cannot be moved to a different file system, a new one has to be created with the permissions rules applicable to the destination file system and the contents have to be copied. The destination file system has no knowledge about where the data come from and what were the original permissions.
Quote:
Is think it would be resonable in my case to delete the full access ACE of Administrator, as Administrators still have full access. What you think?

ntfs-3g cannot differentiate Administrator from Administrators, just try both variants and keep the one which suits your needs best.

Regards

Jean-Pierre


Tue May 06, 2014 11:33
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Hi,
Quote:
Quote:
Have you tried my suggestion on filtering chmod upon it does not effectively change the permissions view from Linux?
No, because there will be situations where chmod changes the permissions in a non-inheritable way, and users will get different behaviors depending on obscure conditions.
Do I understand correct, that the no-chmod.patch only comes to effect if the -inherit option is set? This seems reasonable to me. If it is not set, chmod is effective and only then users may get different behaviors depending on obscure conditions.

Quote:
Quote:
Have you tried to find a solution how to suppress the additional Administrator(s) ACE which is not there if a new folder is created from Windows Explorer?
ntfs-3g is a file system, it will not emulate Windows Explorer.
This is not about Windows Explorer only, using md from Windows command prompt has the same result, see secaudit log below. So I think for maximal compatibility using mkdir with ntfs-3g without UserMapping should create the same result. Would be nice if that would be possible.

Quote:
Quote:
Have you tried to find a solution upon the different inheritance from - higher-level Object vs. E:\Users\Public\ - with ntfs-3g in contrary with Windows behaviour?
Please post again the secaudit output for the parent directory, the inner directory created by the Windows mkdir command, and the one created by the Linux mkdir command. Avoid using applications which may impose their own view on permissions.
Attachment:
Secaudit Public_2.zip [2.75 KiB]
Downloaded 1119 times


Quote:
Quote:
Have you tried to find a solution upon the different behavior of ntfs-3g when moving a folder to a different location with different rights to inherit?
Moving a file or directory within a file system does not change the permissions. A file or directory cannot be moved to a different file system, a new one has to be created with the permissions rules applicable to the destination file system and the contents have to be copied. The destination file system has no knowledge about where the data come from and what were the original permissions.
For my reported screen shot the moves were within same file system. The Windows move correctly processed the inheritance from the destination folder, but Linux move did not.
Attachment:
Secaudit moved_folders.zip [1.81 KiB]
Downloaded 1113 times


Regards

Ulf


Thu May 08, 2014 14:17
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Inherit privileges from parent folder for new created files
Hi,

Quote:
Do I understand correct, that the no-chmod.patch only comes to effect if the -inherit option is set? This seems reasonable to me. If it is not set, chmod is effective and only then users may get different behaviors depending on obscure conditions.

With the no-chmod.patch, chmod is active if and only if the inherit option is not set. This condition is quite obvious to both users who want the Linux behavior and those who want the Windows behavior. By the way the Windows chmod() (from msvcrt.dll) has no effect.
Quote:
This is not about Windows Explorer only, using md from Windows command prompt has the same result, see secaudit log below.

Your posted example is not valid, you used md on Windows as an administrator, and mkdir on Linux as a plain user. Please retry with md on Windows as a plain user, and mkdir on Linux as the same user. "Same user" means a Linux user whose uid (and gid) are mapped to the user you used on Windows.
Quote:
So I think for maximal compatibility using mkdir with ntfs-3g without UserMapping should create the same result.

This is not always possible. Creating a file or directory implies recording the owner and group. When there is no user mapping, owner and group are derived heuristically from the parent directory, and this may be wrong when the parent directory is owned by a different user or when it only shows generic users.
Quote:
For my reported screen shot the moves were within same file system. The Windows move correctly processed the inheritance from the destination folder, but Linux move did not.

Neither Windows nor Linux change the permissions when moving a file or directory within a file system. You probably made your tries with Windows Explorer which messes with the permissions. See for instance the Remarks section on http://msdn.microsoft.com/en-us/library ... 10%29.aspx I have attached a basic program (source and 32-bit and 64-bit executables) which acts directly on the Windows file system without messing with permissions, so that you can check what happens.

I have also attached a global patch file which includes all the patches you may need. I have modified the heuristics for deriving an owner and group, and this may cause regressions, so please test with care. If this is not satisfactory, i will keep the former heuristics.

Regards

Jean-Pierre


Attachments:
inherit2.patches.gz [5.78 KiB]
Downloaded 1091 times
mv.zip [2.99 KiB]
Downloaded 1141 times
Sat May 10, 2014 11:34
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
jpa wrote:
Your posted example is not valid, you used md on Windows as an administrator, and mkdir on Linux as a plain user. Please retry with md on Windows as a plain user, and mkdir on Linux as the same user. "Same user" means a Linux user whose uid (and gid) are mapped to the user you used on Windows.
md as plain user Katrin is not interesting here, as result with mkdir with UserMapping from katrin produced correct same result even when using Explorer/Nautilus, see tuxera.com/forum/viewtopic.php?p=38308&sid=f38ee47430544e4471c81df656e93dfd#p38308
mkdir from root produces same result as mkdir without UserMapping from katrin. Here are the missing logs:
Attachment:
Secaudit Public_3.zip [1.98 KiB]
Downloaded 1112 times


Quote:
Quote:
So I think for maximal compatibility using mkdir with ntfs-3g without UserMapping should create the same result.
This is not always possible. Creating a file or directory implies recording the owner and group. When there is no user mapping, owner and group are derived heuristically from the parent directory, and this may be wrong when the parent directory is owned by a different user or when it only shows generic users.
Currently ntfs-3g records administrator as owner inherits full access for administrator from higher-level Object and adds special permissions for administrator vs. Windows records administrators as owner, inherits full access for administrators from E:\Users\Public\ and does not add an additional ACE. Can't ntfs-3g samely record administrators as owner and set the same ACEs? This is not extremely important, but "would be nice".

For the move problem I have opened a new thread: viewtopic.php?f=3&t=30689

-Ulf


Mon May 12, 2014 14:32
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Another little nit I observed. I don't think, this is really important, but maybe nice to change:
If a folder in Users\Public is created from Windows user Katrin, it is owned by xxx-1007, mapped to "katrin", and belongs to the xxx-513 group, so in Linux it shows the Windows generic group, mapped as "windows" here.
If a folder in Users\Public is created from Linux user katrin, it is owned by xxx-1007, mapped to "katrin", and belongs to the xxx-1007 group, so in Linux it shows the same group "katrin" here.
In case of "inherit" mount option it maybe would be better, to join a Linux-created object to the xxx-513 group, because xxx-1007 = "Katrin" as group assignment is maybe weird for Windows. If you think different, then please change nothing, as I think your are more expert here than me.


Attachments:
Secaudit Public Katrin_mkdir.zip [1.58 KiB]
Downloaded 1054 times
Mon May 12, 2014 18:38
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
jpa wrote:
I have also attached a global patch file which includes all the patches you may need. I have modified the heuristics for deriving an owner and group, and this may cause regressions, so please test with care. If this is not satisfactory, i will keep the former heuristics.

This patch doesn't work :cry:
- If mounted with UserMapping, Users/Public is again not accessible from normal user.
- The owner was always recorded as Katrin (from Windows view), even if there was no UserMapping and/or I executed the mkdir from "sudo -s" terminal in Users/Public and Users/Katrin.


Mon May 12, 2014 21:09
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 71 posts ]  Go to page Previous  1, 2, 3  Next


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Original forum style by Vjacheslav Trushkin.