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



Post new topic Reply to topic  [ 71 posts ]  Go to page Previous  1, 2, 3
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:
If mounted with UserMapping, Users/Public is again not accessible from normal user.

Ok, please retry with disabled Posix ACLs. In the compiling sequence replace "./configure --enable-posix-acls" by "./configure" :
Code:
./configure
make
sudo make install

Quote:
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.

I was expecting all users to be owners of the files or directories they create as a plain user in their own home directory, so this is a regression and I have to step back.

This just means there is no point in making guesses when there is no UserMapping or when the grouping of users is not the same in Windows and Linux (most importantly the primary group of each user). If the current situation does not suit your needs, I will just cancel the patches for allowing inherit without UserMapping and the one for guessing the user.

Regards

Jean-Pierre


Tue May 13, 2014 16:18
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:
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.

I was expecting all users to be owners of the files or directories they create as a plain user in their own home directory, so this is a regression and I have to step back.
Now, after compiling without --enable-posix-acls, Users/Public is again accessible from normal user and the permissions from Windows view look good.

Quote:
This just means there is no point in making guesses when there is no UserMapping or when the grouping of users is not the same in Windows and Linux (most importantly the primary group of each user). If the current situation does not suit your needs, I will just cancel the patches for allowing inherit without UserMapping and the one for guessing the user.
IMO I think:
- If there is no UserMapping and no inherit option, uid and gid should be set to root, even in Windows home directories.
- If there is inherit option, permissions should inherit from the parent folder, equal to a new object, created from Windows, even if there is no UserMapping.
- root should be mapped to Administrators, not to Administrator
- If there is a no mapping to the Windows default group, it's discussable to set the gid to root or to the owner of a new created object.
- The gid part of a user mapping, e.g. :katrin:katrin: should override a given mapping to the Windows default group for a new created object.

Cheers, Ulf


Thu May 15, 2014 19:40
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Here are the logs:
Attachment:
Secaudit Katrin_mkdir-inherit2.zip [1.57 KiB]
Downloaded 940 times

Attachment:
Secaudit Public_mkdir-inherit2.zip [2.73 KiB]
Downloaded 983 times


Thu May 15, 2014 19:53
Profile

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

UlfZibis wrote:
Now, after compiling without --enable-posix-acls, Users/Public is again accessible from normal user and the permissions from Windows view look good.
Ok, they look good from Windows Explorer properties, but under the hood, group ownership is different for objects created with ntfs-3g vs. Windows. This causes an ugly error on Linux view:
The permissions of an object created as root from Linux in Users/Katrin has mode 0000 permissions, so is not accessible from Linux. See secaudit log for Users/Katrin/mkdir_root_inherit2:
Owner SID
Local admins SID
O:hex S-1-5-20-220
O:dec S-1-5-32-544
Group SID
Local admins SID
G:hex S-1-5-20-220
G:dec S-1-5-32-544
Interpreted Unix owner 1000, group 0, mode 0000

Users/Katrin/md_from_Administrator:
Owner SID
Local admins SID
O:hex S-1-5-20-220
O:dec S-1-5-32-544
Group SID
Local users SID
G:hex S-1-5-15-ab0b4702-a98d9886-ee1678a6-201
G:dec S-1-5-21-2869643010-2844629126-3994450086-513
Interpreted Unix owner 1000, group 1003, mode 0700

So I think, NTFS-3G should always record the same Windows group SID ...-513 for new created objects.
Also, I think, the interpreted Unix owner is wrong, it should be 0 instead 1000.

Same "problem" at Users/Katrin/mkdir_katrin_inherit2:
Owner SID
Local user-1007 SID
O:hex S-1-5-15-ab0b4702-a98d9886-ee1678a6-3ef
O:dec S-1-5-21-2869643010-2844629126-3994450086-1007
Group SID
Local user-1007 SID
G:hex S-1-5-15-ab0b4702-a98d9886-ee1678a6-3ef
G:dec S-1-5-21-2869643010-2844629126-3994450086-1007
Interpreted Unix owner 1000, group 1000, mode 0700

I think, "Katrin" as Group SID at Windows doesn't make sense, it should be ...-513

Is it possible to change that?
If yes, than inherit2.patch seems perfect.


Fri May 16, 2014 15:41
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:
So I think, NTFS-3G should always record the same Windows group SID ...-513 for new created objects.

Hardcoding a group this way is not desirable. It is a behavior of Windows 7 which has been changed in Windows 8. ntfs-3g does not emulate Windows, it only provides file system services.
Quote:
Is it possible to change that?

Yes.

You need to have the same primary group for each users in Windows and Linux. In Windows 7 all users are (at least by default) in the same primary group (SID ..-513), and in Linux you still have a specific primary group per user.

To change the bahavior you get, either :
- define the same primary group for all users,
- or switch to Windows 8 to get one group per user.
(I do not know how to have an individual group per user with Windows 7)

Regards

Jean-Pierre


Fri May 16, 2014 21:29
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
jpa wrote:
Quote:
So I think, NTFS-3G should always record the same Windows group SID ...-513 for new created objects.

Hardcoding a group this way is not desirable. It is a behavior of Windows 7 which has been changed in Windows 8. ntfs-3g does not emulate Windows, it only provides file system services.
I agree, that hardcoding is bad. But from secaudit and usermap I'm wondering how you can determine "Local users SID" as mapping to ..-513, so can't you record the SID of "Local users SID". If on Windows 8 this group is mapped to a different SID or is not existing, you maybe could process different there for creating new objects.
As a workaround you maybe could inherit the group SID from the parent folder if there is no UserMapping, or if there is you could use the group SID from the UserMapping.
Anyway, creating a folder from root and after have no access as root (mode 0000) should not happen, have you found the reason for that?

It would be nice, if the inherit option could be seen as "emulate Windows behavior" as best as possible.

Quote:
You need to have the same primary group for each users in Windows and Linux. In Windows 7 all users are (at least by default) in the same primary group (SID ..-513), and in Linux you still have a specific primary group per user.

To change the bahavior you get, either :
- define the same primary group for all users,
- or switch to Windows 8 to get one group per user.
(I do not know how to have an individual group per user with Windows 7)
On my Ubuntu the primary group for each user is it's same id. I don't know the reason for that concept, so I'm afraid to change that. Would it help to change the UserMapping from this:
Code:
:windows: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
to this:
Code:
:windows:S-1-5-21-2869643010-2844629126-3994450086-513
jakob::S-1-5-21-2869643010-2844629126-3994450086-1005
lasse::S-1-5-21-2869643010-2844629126-3994450086-1006
katrin::S-1-5-21-2869643010-2844629126-3994450086-1007
?


Sat May 17, 2014 18:47
Profile

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

now I'm a little confused, which patch I should use for my needs.
The inherit2.patch produces situations which look very good from 1. view with Windows Explorer properties. But there is the lack of not using the Windows default group SID and the ugly mode 0000 case, which may be fairly seen as academic, because creating an object in a user home folder from root login is aside normal usage.
The combination of your other patches seems to produce a working situation from Windows view, but has other lacks. E.G. samely not using the Windows default group SID, the difference in inheriting from higher-level Object vs. E:\Users\Public\, recording Administrator instead Administrators SID for the owner and the superfluous ACE. The 3 latter problems may be academic too, maybe it's Windows "fault/inconsequence" to inherit from direct parent folder instead higher-level Object for new created objects.

I'm asking this, because I want to be most compatible to future enhancements of NTFS-3G. Have you already decided, which of the discussed changes you want to implement in next releases?
Unfortunately I have to bring back the testing-machine, which was provided by a friend. This may be monday, but not much later. I would like to make final tests with this machine and then there install the best solution.

Is there a detailed description how the NTFS-3G NTFS-Linux mapping is designed?

Because Windows 7 and 8 behave different upon the group SIDs, I'm wondering, if Windows XP would behave in a 3rd different manner. I plan to check that in the next days.

Finally much thanks to you, developing NTFS-3G in general and your time for discussing the current problems.

Ulf


Sun May 18, 2014 14:26
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,

Sorry for not being much present now, I have deadlines to meet before the summer season, and I cannot start new developments for some time. My view is that you have a usable configuration with the latest patch set (inherit2.patch).
Quote:
But there is the lack of not using the Windows default group SID

Please do not blame that on ntfs-3g, it is because you have a different grouping of users in Linux and Windows.
Quote:
the ugly mode 0000 case, which may be fairly seen as academic, because creating an object in a user home folder from root login is aside normal usage.

This is complex to explain, the essential point is that home directories are owned by admin, so from the Linux point of view, this directory is not owned by the user and has no permission for his/her group or other users. In other words, the user would not be able to access his/her own home directory from Linux.
In such situation, the Linux owner is forced to be the user who has the permission to change the owner (there is a warning in secaudit output when this happens). The 000 is an unwanted consequence, and I have not yet analyzed if it can be fixed and how.
Quote:
recording Administrator instead Administrators SID for the owner and the superfluous ACE.

This is mostly caused by your non standard Public directory, which has a reference to a local administrator, because it was created by the local administrator and not by the system. It is another consequence of the user redefinition mentioned above. This problem does not exist with the standard Public directory on Vista, Windows 7 and Windows 8.
Quote:
Windows "fault/inconsequence" to inherit from direct parent folder instead higher-level Object for new created objects.

The problem which Windows has to solve is that a file can have multiple names in different directories which have different inheritance parameters, so a file cannot inherit from all its parent directories. This happens frequently on Windows 8, and the choice was to only inherit when the first name is defined, but Internet Explorer has decided otherwise.
Quote:
I'm asking this, because I want to be most compatible to future enhancements of NTFS-3G. Have you already decided, which of the discussed changes you want to implement in next releases?

I have not yet decided. Right now, I would capitalize on inherit2.patch and cancel the ability to inherit without a user mapping. Keeping it would only lead to user disappointment. Anyway I have no time to make a new release in the coming weeks.
Quote:
Is there a detailed description how the NTFS-3G NTFS-Linux mapping is designed?

Quite straitforward : Linux having users Ukatrin, Ulassie, etc, and groups Gsales, Gdevelopers, etc... Windows having users Wkatrin, Wlassie, ... and groups Wsales, Wdevelopers, etc. (for Windows you have to use sequences of numbers, I use names for clarity).
A line Ukatrin::Wkatrin means Ukatrin and Wkatrin are the same user,
A line :Gsales:Wsales means Gsales and Wsales are the same group
A line Ukatrin:Gsales:Wkatrin means Ukatrin and Wkatrin are the same user, and the group Gsales and Wkatrin are the same group, which implies the Windows user and Windows group have the same code (this is a usual configuration for Windows 8, but it is unusual on Windows 7). This line does not imply that Ukatrin is in group Gsales.
Accounts and groups for all Windows end users and all Linux end users have to be defined. When a mapping is not available, root/administrator is used instead.
Quote:
Because Windows 7 and 8 behave different upon the group SIDs, I'm wondering, if Windows XP would behave in a 3rd different manner. I plan to check that in the next days

Windows 7 behaves similarly to Windows XP, but Windows XP has no Public directory, and the home directories are in "Documents and Settings".

Regards

Jean-Pierre


Sun May 18, 2014 20:10
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
jpa wrote:
Quote:
But there is the lack of not using the Windows default group SID
Please do not blame that on ntfs-3g, it is because you have a different grouping of users in Linux and Windows.
I was thinking, if you can determine the "Local users SID", as seen in secaudit output, you could use it as group ID while creating a new object. There seems to be a reason why you can't do this, which I respect.

Quote:
Quote:
the ugly mode 0000 case, which may be fairly seen as academic, because creating an object in a user home folder from root login is aside normal usage.
This is complex to explain, the essential point is that home directories are owned by admin, so from the Linux point of view, this directory is not owned by the user and has no permission for his/her group or other users. In other words, the user would not be able to access his/her own home directory from Linux.
In such situation, the Linux owner is forced to be the user who has the permission to change the owner (there is a warning in secaudit output when this happens). The 000 is an unwanted consequence, and I have not yet analyzed if it can be fixed and how.
Thanks for your detailed explanation. Take the time you need to find a solution. In the meantime I'm fine, to not create objects in a users home folder from root login.

Quote:
Quote:
recording Administrator instead Administrators SID for the owner and the superfluous ACE.
This is mostly caused by your non standard Public directory, which has a reference to a local administrator, because it was created by the local administrator and not by the system. It is another consequence of the user redefinition mentioned above. This problem does not exist with the standard Public directory on Vista, Windows 7 and Windows 8.
Well, the owner here is Administrators, not Administrator. Even for C:\Users it is Administrators, not SYSTEM. Anyway I will look at this when I do a new Windows 7 installation. In the current installation I will manually remove the Administrator reference and test again.

Quote:
Quote:
I'm asking this, because I want to be most compatible to future enhancements of NTFS-3G. Have you already decided, which of the discussed changes you want to implement in next releases?
I have not yet decided. Right now, I would capitalize on inherit2.patch and cancel the ability to inherit without a user mapping. Keeping it would only lead to user disappointment.
I don't understand why. Users would have always the choice to voluntarily define a UserMapping to avoid the thinkable "disappointment". I estimate, dealing with a UserMapping would often be a hurdle to many users to benefit from the inherit advantages at all.

Quote:
Quote:
Is there a detailed description how the NTFS-3G NTFS-Linux mapping is designed?

Quite straitforward : Linux having users Ukatrin, Ulassie, etc, and groups Gsales, Gdevelopers, etc... Windows having users Wkatrin, Wlassie, ... and groups Wsales, Wdevelopers, etc. (for Windows you have to use sequences of numbers, I use names for clarity).
A line Ukatrin::Wkatrin means Ukatrin and Wkatrin are the same user,
A line :Gsales:Wsales means Gsales and Wsales are the same group
A line Ukatrin:Gsales:Wkatrin means Ukatrin and Wkatrin are the same user, and the group Gsales and Wkatrin are the same group, which implies the Windows user and Windows group have the same code (this is a usual configuration for Windows 8, but it is unusual on Windows 7). This line does not imply that Ukatrin is in group Gsales.
Accounts and groups for all Windows end users and all Linux end users have to be defined. When a mapping is not available, root/administrator is used instead.
I think, root/Administrators would be better. Anyway thanks for your detailed description upon user/group mapping, but I also meant the mapping heuristics of the permissions.

Quote:
Windows 7 behaves similarly to Windows XP, but Windows XP has no Public directory, and the home directories are in "Documents and Settings".
Thanks again, but I think there is a kind of public directory in Windows XP too, named as "All Users".


Mon May 19, 2014 01:05
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
jpa wrote:
... and cancel the ability to inherit without a user mapping.
Additionally it's unclear to me, how you otherwise would like to solve the problem from Bug 1249674 - New objects should inherit limited access rights from above instead insecurely being world accessible.


Mon May 19, 2014 15:20
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
With the new inherit2.patch I discovered an additional problem.
If there is no UserMapping and a new object is created with root login in a Windows home directory, e.g. Users/Katrin, Katrin is recorded as owner instead Administrators. The same unexpected behavior happens if without UserMapping a new object is created from user katrin login. I think, the latter action should be treated as same as from root login, as in this case there is no valid user known from Linux view.


Wed May 21, 2014 22:31
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Big Problem with inherit2.patches ...

Hi Jean-Piere,

I now have started to use your patches on my working machine (Windows7 Ultimate + Ubuntu 14.04):
1.) Because I used the NTFS-3G without inheritance and UserMapping, there were many files with "full access to world" permissions on my shared data partition.
2.) From Windows I have used the Windows Explorer security properties function to inherit recursively the ownership and permissions on my shared data partition.
3.) On Ubuntu I have patched NTFS-3G with inherit2.patches.
4.) ntfs mount options: default, inherit,hide_dot_files
5.) The UserMapping on D:\Users\Daten\ is:
Code:
:windows:S-1-5-21-a-a-a-513
user::S-1-5-21-a-a-a-1004
::S-1-5-21-a-a-a-10000

With this I had no access to many files on that partition, which I didn't realise from the beginning, so it caused my Firefox profile to become damaged. It was some work to restore most of the data from old backups.
The cause for the problem seems following:
All files, created from old NTFS-3G driver then had:
Code:
Owner SID
    Local user-1004 SID
    O:dec S-1-5-21-a-a-a-1004
Group SID
    Local admins SID
    G:dec S-1-5-32-544
Interpreted Unix owner 1000, group 0, mode 0000
But files, created from Windows had:
Code:
Owner SID
    Local user-1004 SID
    O:dec S-1-5-21-a-a-a-1004
Group SID
    Local users SID
    G:dec S-1-5-21-a-a-a-513
Interpreted Unix owner 1000, group 1001, mode 0700

So I had to use your older patches set, which I will call inherit1.patches from now.
But with these, there are other knows problems, as you know.

I respect, you have few time at the moment, but I want to ask you, if you can provide a hint, how I can change recursively all the group SIDs from S-1-5-32-544 to S-1-5-21-a-a-a-513.
This would be a very nice help, so I could use inherit2.patches from now on.

Thanks Ulf


Tue May 27, 2014 14:44
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
With inherit1.patches I now have another problem ...

I can not access my old backup partition from user login, but only from root, when using the UserMapping, so I have to abdicate from UserMapping here :-(
Attachment:
Secaudit Sicherung inherit1.zip [4.26 KiB]
Downloaded 959 times


Another curiosity! Files, copied from my Firefox profile backup with inherit1.patches now have:
Owner SID
Local user-1004 SID
Group SID
Local user-12001 SID
Interpreted Unix owner 1000, group 1000, mode 0700
I don't know, where user-12001 comes from.


Attachments:
Secaudit Sicherung inherit1.zip [4.26 KiB]
Downloaded 928 times
Tue May 27, 2014 16:02
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 respect, you have few time at the moment, but I want to ask you, if you can provide a hint, how I can change recursively all the group SIDs from S-1-5-32-544 to S-1-5-21-a-a-a-513.

Do a full image backup of your partition before it gets too late ! Your files have been created with a diversity of patches and mappings which is becoming too difficult to understand and fix.
I have no immediate solution for changing a group, other than copying the file hierarchy with Windows tools, thus redefining the owners and groups (each user must copy his/her own files under his/her account).
Quote:
Group SID
Local user-12001 SID
Interpreted Unix owner 1000, group 1000, mode 0700
I don't know, where user-12001 comes from.

This comes from some program (possibly Firefox), running on a user account whose primary group is gid=1000. If you did not map the group 1000, a specific group SID is used, based on the generic mapping line "::S-1-5-21-a-a-a-10000".
Quote:
:windows:S-1-5-21-a-a-a-513
user::S-1-5-21-a-a-a-1004
::S-1-5-21-a-a-a-10000

This mapping is probably wrong : I see no definition for the primary group the user is in (the group windows is probably not the primary group).

Please do what I tell you : you need to have matching primary groups on Linux and Windows for each user, and you have to use a correct user mapping file.

Regards

Jean-Pierre


Tue May 27, 2014 17:14
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Also with inherit2.patches + UserMapping the unknown user-12001 SID is recorded:
Attachment:
Secaudit touch new inherit2+UMap.zip [1.34 KiB]
Downloaded 993 times


Tue May 27, 2014 17:28
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 again,

Quote:
Also with inherit2.patches + UserMapping the unknown user-12001 SID is recorded:

Which is what is to be expected, if you do not map the primary group 1000.

Regards

Jean-Pierre


Tue May 27, 2014 18:13
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
jpa wrote:
Do a full image backup of your partition before it gets too late ! Your files have been created with a diversity of patches and mappings which is becoming too difficult to understand and fix.
Backup is always good idea, but do not mix with the machine I have used for the experiments the last weeks. My working machine was never used with patches since yesterday.

Quote:
I have no immediate solution for changing a group, other than copying the file hierarchy with Windows tools, thus redefining the owners and groups (each user must copy his/her own files under his/her account).
Thanks for this hint, just copying back and forth with Windows is a manageable procedure.

Quote:
Quote:
I don't know, where user-12001 comes from.
This comes from some program (possibly Firefox),
I don't think, this has something to do with Firefox, because "touch NewFile" behaves the same as you can see from my last post.

Quote:
... running on a user account whose primary group is gid=1000. If you did not map the group 1000, a specific group SID is used, based on the generic mapping line "::S-1-5-21-a-a-a-10000".
Aha, I didn't know that. And why don't you map this as group SID instead Local admins SID when logged in as root? I guess this would probably workaround some problems we have talked about the last weeks, even I more would like to use the SID which is classified by secaudit as "Local users SID" (I would not see this as "hardcoding", as I guess , on another machine/OS "Local users SID" has a different value).

Quote:
Quote:
:windows:S-1-5-21-a-a-a-513
user::S-1-5-21-a-a-a-1004
::S-1-5-21-a-a-a-10000
This mapping is probably wrong : I see no definition for the primary group the user is in (the group windows is probably not the primary group).
Please do what I tell you : you need to have matching primary groups on Linux and Windows for each user, and you have to use a correct user mapping file.
You mean, I should use: user:user:S-1-5-21-a-a-a-1004 ?
But sorry, with that I'm a little confused, because on http://www.tuxera.com/community/ntfs-3g ... rmissions/ you write:
Defining a uid and a gid for the same SID may lead to bad compatibility with Windows and should be avoided, moreover for better compatibility the (user, default group) pairs should be the same on both systems.
I just wanted to follow this rule, even usermap.exe outputs "user:user:...-1004".

Another curiosity with inherit1.patches. The same SID/SID pair is interpreted as different uid/gid for different objects in same parent folder. How can this happen? :
Attachment:


Tue May 27, 2014 19:33
Profile

Joined: Mon Mar 31, 2014 13:43
Posts: 113
Post Re: Inherit privileges from parent folder for new created files
Another additional thoughts ...
As I now see, that on NTFS there are distinct SIDs for user and group, even if the latter was not really used before Windows 8, I do nor understand why you map a uid/gid pair to a single SID.
Wouldn't something like the following solve the needs better? :
Code:
uid:gid:user_SID:group_SID
:gid::group_SID     # if upper pair(s) do not match
uid::user_SID:      # if upper pair(s) do not match


Tue May 27, 2014 20: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:
As I now see, that on NTFS there are distinct SIDs for user and group, even if the latter was not really used before Windows 8, I do nor understand why you map a uid/gid pair to a single SID.

Please login on Linux successively as each user, and type the command "id", for each user you will probably get a line such as :
Code:
uid=500(john) gid=500(john) groups=500(john),18(dialout)
uid=501(mary) gid=501(mary) groups=501(mary),18(dialout)

If you get different values for gid, such as in the example above, you cannot map these different values to a single SID, which is what is required by Windows 7.
You need to get :
Code:
uid=500(john) gid=499(family) groups=499(family),500(john),18(dialout)
uid=501(mary) gid=499(family) groups=499(family),501(mary),18(dialout)

If you do not want to organize your Linux groups so that the gid (the primary group) of each user is the same, you will have to tolerate approximations.

Regards

Jean-Pierre


Tue May 27, 2014 21:51
Profile

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

thanks for your additional answer, even I miss some.

Code:
uid=500(john) gid=500(john) groups=500(john),18(dialout)
uid=501(mary) gid=501(mary) groups=501(mary),18(dialout)
Yes, this is what I have here at Ubuntu by default.

Quote:
If you get different values for gid, such as in the example above, you cannot map these different values to a single SID, which is what is required by Windows 7.
I do not want to map different single gids to a single SID, I want to map a pair of uid/gid to a pair of user_SID/group_SID. Then group_SID could be the same for different pairs.

Quote:
If you do not want to organize your Linux groups so that the gid (the primary group) of each user is the same, you will have to tolerate approximations.
I'm planning to ask in some Ubuntu forum, if this would hurt something.


Wed May 28, 2014 00:58
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.

In the meantime I had the chance for inspect 2 fresh new Windows 7 installations.
- One was with a Windows 7 Ultimate Upgrade DVD on a normal laptop. In this case the C:\Users/Public folder had the same permissions with full access for world as you send me from your installation.
- The other was a Windows 7 Starter from the vendors recovery partition on a small netbook. In this case the C:\Users/Public folder doesn't full access permission for world as on the original system regarding this bug.
Attachment:
Secaudit UsersPublic Win7Starter.zip [1.22 KiB]
Downloaded 935 times


To me, the second one makes more sense, as if there would be full access for world, all the other permissions are superfluous. Maybe the difference occurs upon a slight difference, how the network was configured, e.g. as "Home Network" or "Workplace Network". I do not know really.


Sun Jun 29, 2014 17:14
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 71 posts ]  Go to page Previous  1, 2, 3


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:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Original forum style by Vjacheslav Trushkin.