The above file contains this code: bool inherit_owner = lp_inherit_owner(SNUM(fsp->conn)); bool inheritable_components = false; size_t size = 0; if (!parent_dirname(ctx, fsp->fsp_name->base_name, &parent_name, NULL)) { return NT_STATUS_NO_MEMORY; } status = SMB_VFS_GET_NT_ACL(fsp->conn, parent_name, (SECINFO_OWNER | SECINFO_GROUP | SECINFO_DACL), &parent_desc); if (!NT_STATUS_IS_OK(status)) { return status; } inheritable_components = sd_has_inheritable_components(parent_desc, fsp->is_directory); if (!inheritable_components && !inherit_owner) { /* Nothing to inherit and not setting owner. */ return NT_STATUS_OK; } However, if the parent directory does not contain any inheritable entries, which a user can do, and the admin has not set inherit owner, then the file ends up without an owner or group SID. I believe that in that case, Windows would at least set the owner SID and the group SID in the SD.
I have actually verified that thos problem exists, at least with the Samba 3.5.12 code in modules/acl_xattr_common.c, but the responsible code has migrated into smbd/open.c It is interesting that W2K03, at least, seems to create ACEs for the CREATOR and the GROUP that gives them Full Control. (Even though there are no inheritable ACEs on the parent.)
Here is what Windows 2K03 does in that case: REVISION:1 OWNER:TESTAD\mtest1 GROUP:TESTAD\Domain Users ACL:TESTAD\mtest1:ALLOWED/0/FULL ACL:NT AUTHORITY\SYSTEM:ALLOWED/0/FULL Here is what the SD looks like on the parent: REVISION:1 OWNER:BUILTIN\Administrators GROUP:TESTAD\Domain Admins ACL:BUILTIN\Administrators:ALLOWED/0/FULL ACL:TESTAD\Domain Users:ALLOWED/0/FULL ACL:NT AUTHORITY\SYSTEM:ALLOWED/0/FULL
There is an additional interesting thing to note here. A user loged in as DOM\Administrator (or MACHINE\Administrator) has the following token (extracted using the Windows debugger): 1: kd> !token Thread is not impersonating. Using process token... _EPROCESS fffffadfce265040, _ETHREAD fffffadfce02d040, _TOKEN fffffa80001cb060 TS Session ID: 0 User: S-1-5-21-3518369957-2465764196-3682812194-500 Groups: 00 S-1-5-21-3518369957-2465764196-3682812194-512 Attributes - Mandatory Default Enabled 01 S-1-1-0 Attributes - Mandatory Default Enabled 02 S-1-5-32-544 Attributes - Mandatory Default Enabled Owner 03 S-1-5-32-545 Attributes - Mandatory Default Enabled 04 S-1-5-4 Attributes - Mandatory Default Enabled 05 S-1-5-11 Attributes - Mandatory Default Enabled 06 S-1-5-15 Attributes - Mandatory Default Enabled 07 S-1-5-5-0-808621 Attributes - Mandatory Default Enabled LogonId 08 S-1-2-0 Attributes - Mandatory Default Enabled 09 S-1-5-21-3518369957-2465764196-3682812194-513 Attributes - Mandatory Default Enabled 10 S-1-5-21-3518369957-2465764196-3682812194-520 Attributes - Mandatory Default Enabled 11 S-1-5-21-3518369957-2465764196-3682812194-1103 Attributes - Mandatory Default Enabled 12 S-1-5-21-3518369957-2465764196-3682812194-519 Attributes - Mandatory Default Enabled 13 S-1-5-21-3518369957-2465764196-3682812194-518 Attributes - Mandatory Default Enabled 14 S-1-5-21-3518369957-2465764196-3682812194-572 Attributes - Mandatory Default Enabled GroupResource Primary Group: S-1-5-21-3518369957-2465764196-3682812194-512 However, files created by this user are marked as being owned by S-1-5-32-544 (ie, BUILTIN\Administrators), which is not the user SID of the process. I don't currently understand the logic Windows uses here, although maybe it ises the SID of the parent directory if the user has that SID in its token.
Aha, there's the answer: 02 S-1-5-32-544 Attributes - Mandatory Default Enabled Owner Note also, that MACHINE\Administrator would likely have a different set of SIDs in its token.
More info here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa379624(v=vs.85).aspx
And this contains more info: http://msdn.microsoft.com/en-us/library/windows/hardware/ff556842(v=vs.85).aspx Looks like I actually need to dump the token owner info to make the conclusion I did above.