Creator/Owner permissions - broken / wrong.

[djmuk]

I am trying to set up user folder redirections under SBS 2011 to a freenas box. Fundamental to this is the use of 'creator owner' (which I will abbreviate to C/O) permissions, to correctly create directories only accessible to the specific user and defined others (EG domain admins).
The root folder has the following permissions (As per numerous MS documents)
Domain Admins - full, this folder & sub folders
Domain users - read, execute, traverse, create folder (THIS FOLDER ONLY)
Creater Owner - full, this folder and sub folders.
What should happen is that a folder is created as each user, they are the owner of that folder and so (under windows) are granted full rights to that folder as per the C/O permissions. This done by creating an EXPLICIT ACE for that user.
Under Samba/freenas this does not happen, the C/O full permission is propagated to the subfolder but the user DOES NOT have any access.
I think the most succinct explanation of C/O under windows is here:
http://networkadminkb.com/KB/a80/creator-owner-explained.aspx

How “Creator Owner” works
The “Creator Owner” group is unique because when applied to a folder the following permission changes happen.
1)The Owner (creator) of the object is “semi-statically” assigned the same permissions as the original “Creator Owner” group. These permissions are “semi-static” because if you remove the “Creator Owner” group the permissions for the user are removed as well.
2)If the owner of an object changes, the permissions on the object do not change to the new owner.
3)If the object created is a Folder, the “Creator Owner” group is re-applied to the newly created folder, along with the permission listed in Item 1.

There is a long discussion in the samba bug thread here
https://bugzilla.samba.org/show_bug.cgi?id=9467#
and I think they have made it complicated by asuming that the C/O right is somehow dynamic - it isn't it is a 'hint' to create a static ACE (point 1 above) when the folder is created, the only complication is that the ACE needs to be removed if the C/O ACE entry is removed.

I have attached a PDF showing various tests against a freenas box and a windows SBS 2011 box. Freenas is current version (FreeNAS-9.2.1.6-RELEASE-x64 (ddd1e39))

 

[cyberjock]

Ok, few things you need to understand:

1. Samba 3.x and 4.x are totally different in how they actually handle permissions. So I think it's a major error to assume a bug that says Samba 3.6 applies to 4.x.
2. Samba 4.x behaves totally different from 3.x with regards to permissions. This is one of the reasons why <9.2.1 and 9.2.1+ don't work the same. Many people had working systems on 9.2.0 and suddenly after upgrading they didn't. This wasn't because of a bug. This wasn't even because of FreeNAS. This was because Samba 4 doesn't do things the same as Samba 3. I'm working on a permissions "guide" and it will be very clear in what is and isn't applicable. At the very beginning it very clearly says that if you are NOT running 9.2.1.6 or higher then my guide will NOT apply to you and will NOT work for you. That's the plain and simple truth.
3. Yes, Creator/Owner is unique. Most people don't get it and I plan to explain it in a little detail in my "guide".

 

[djmuk]

1; I didn't intend to say the bug applied - the discussion covered the C/O permissions and I actually think they have misinterpreted how it works in windows.
2; I'm not arguing! My point is that the permissions in Freenas (using Samba 4) do not behave in the same way as the corresponding permissions under windows / SBS, as Samba is intended to be a replacement for a windows server it should behave the same way as a windows server... As I haven't used Samba 3 in the same way I am not comparing it with Samba 3 but with a windows server.
3; From my reading I agree - it is unique and I don't think the implementation in S4 is right...
At present this is a show stopping problem with respect to using a freenas box for a folder redirection host within a windows environment - having to manually create folders and assign permissions is not a solution...

 

[cyberjock]

1; I didn't intend to say the bug applied - the discussion covered the C/O permissions and I actually think they have misinterpreted how it works in windows.
2; I'm not arguing! My point is that the permissions in Freenas (using Samba 4) do not behave in the same way as the corresponding permissions under windows / SBS, as Samba is intended to be a replacement for a windows server it should behave the same way as a windows server... As I haven't used Samba 3 in the same way I am not comparing it with Samba 3 but with a windows server.
3; From my reading I agree - it is unique and I don't think the implementation in S4 is right...
At present this is a show stopping problem with respect to using a freenas box for a folder redirection host within a windows environment - having to manually create folders and assign permissions is not a solution...

I'm not arguing either. I'm just trying to provide some info. ;)

What I have found is that people who have been using Windows Servers, sometimes for a decade, somehow never actually learned permissions in Windows. It's amazing to me that the percentage of people that understand is smaller than the people that don't. That being said, there is a certain amount of "conversion" going on as NFSv4 permissions bits are more versatile than the permissions bits in NTFS. So there isn't exactly a one-for-one conversion. Of course, if you are always setting things from your Windows clients on FreeNAS machines you can easily ensure they always work properly. For example, setting "read permissions" in NFS is the same as "read permission, read directory listing, read permissions and read extended attributes" (or something like that).

I can't agree or disagree with your assessment of Samba4's implementation being substandard or not. The real problem (and its a major one) is that Samba provides almost zero documentation on how it handles permissions. So literally everyone shoots in the dark with Samba4 unless you want to read the code. Even as I was writing my guide I showed the iX Samba4 lead developer a "feature" in Samba4 he was unaware of. Literally you have to learn by experimenting. This is obviously not the most ideal for most people, hence iX has sanctioned a guide to be written.

I will tell you that on my test box when I create folders the permissions do NOT have to be assigned manually. They propagate properly per your inherited permissions and that does work properly. So when you say you have to manually create folders and assign permissions I immediately think that you are not setting up inherited permissions properly (and may or may not understand those yourself).

I will tell you that after committing myself to writing the permissions guide I'm a little at a loss as to how I am going to write the guide and have it not be 100 pages. It's not simple, it doesn't make sense if you don't do permissions for a living and it still may not make sense even if you DO do it for a living. I've met quite a few people that claim to do it for a living and yet they fubar the heck out of permissions and think they are doing it right.

 

[djmuk]

The permissions inherit properly APART FROM C/O permissions...
As per my attached PDF - on a windows box the C/O permissions cause an explicit ACE to be created for the user creating the folder or file, this ACE implements (for that user) the C/O permissions that are set in the parent folder and then the C/O permissions propagate to the new folder as 'subfolder and files' only (because the required permissions are now implemented on the new folder by the ACE).
In Samba 4 all that happens is that the C/O permissions are inherited into the new folder as 'this folder, subfolders and files' and the creator/owner does not have any permissions to access the new folder - seriously broken IMHO... The only way to make it work is to manually create the ACE for the user. Yes the C/O entry exists but it doesn't have any effect...

 

[djmuk]

Bug ref 5542 is probably closely related - rather concerning quote from that bug "there are no more releases planned in the 9.2.1 branch series. The time to mark this urgent, and report this in time for 9.2.1.6, would have been in a BETA or Release Candidate since we have no software update mechanism in 9.2.1.6 and hence no way to fix this in the field" - as the original poster said 'Just wait for more production environments to upgrade to this version".

Right off to get hold of an older version...

 

[djmuk]

I am not sure if I have found a fix or a workaround... Tested initially on 9.2.1.5 but then confirmed as working on 9.2.1.6

I set the nfs4:mode = simple (in the auxiliary parameters box of the CIFS share) and it works EXACTLY as per a windows server - explicit ACEs are created for the owner for 'this folder only', the C/O permissions inherit as 'files & subfolders only' AND the ACEs are even removed if the C/O permissions are removed from the parent directory.... and reinstated if the C/O permissions are put back on the parent directory...

What is 'interesting' is that a subfolder on a separate share works correctly without that setting on the specific share.

 

[Idiotzoo]

I'm running 9.2.1.6 and agree that creator/owner is broken. Although the behaviour I'm seeing is possibly different. I'm find the creator/owner permission won't stick. I want to use a share for windows roaming profiles so I'm trying to give creator/owner full control of subfolders and files. The correct permissions are applied, but creator/owner immediately disappears from the share permission list and will not stick.

The same applies to other built in users/groups like 'system'. It looks like Freenas doesn't understand these special users/groups.

 

[Idiotzoo]

ok... So CIFS still doesn't work properly... and frustratingly the dev team don't quite get some of the issues... or so it appears... anyway this does seem to be covered in bug 5542

 

[Idiotzoo]

ok.... now this is starting to get weird. I have two freenas 9.2.1.6 boxes. I'm seeing this problem on one of them (our live server) but not on the backup box. Neither have any aux parameters for cifs. Both are talking to the same AD domain.

 

[Idiotzoo]

The plot thickens.... One box will not let me set creator/owner and have that stick. The other will, but the permission doesn't actually work and the creator/owner of a subfolder can't access it.

 

[Idiotzoo]

I'm still struggling with this problem, but things are really odd now. I've updated both my boxes to 9.2.1.18 and one of them (replication destination) appears to work fine, allowing creator/owner to be applied and stick and work... The other box (our main NAS) applies permissions based on who is currently the owner and then immediately removes the creator/owner special user from the permissions list.

I can see nothing different in CIFS settings between these two boxes.

Any thoughts on how I might debug this?

 

[yois]

Any update on this? We're up to 9.3.1 and this doesn't seem to be addressed!