ERROR_ACCESS_DENIED setting file owner

Question

I am trying to set the owner of a file to another user programmatically in C++.

I have definitely enabled the SeRestorePrivilege for my process. I can confirm this using Process Explorer. I start the process, it is disabled, I run my code to enable it, ProcExp reports it as enabled, I go just up to the point where the owner is to be set, and it is still enabled (i.e. I am not accidentally disabling it).

What other caused can there be for this access is denied message? What have I not considered?

std::wstring fileSystemObject = L"C:\test.txt";
*status_code = SetNamedSecurityInfo((wchar_t*)fileSystemObject.c_str(), SE_FILE_OBJECT, OWNER_SECURITY_INFORMATION, pSID, NULL, NULL, NULL);
if (*status_code == ERROR_SUCCESS)
{
    Log(L"Successfully set owner for " + fileSystemObject);
    return true;
}
else
{
    Log(L"Failed to set owner for " + fileSystemObject + L". Error code: ", *status_code);
    return false;
}

Thank you.

EDIT: Thank you very much for your continued assistance. It is greatly appreciated.

I used your code for all of the following tests. Basically, I am also getting Access Denied messages from your code, however, I have tracked it down a little more.

Firstly, "C:\test.txt" was not my real code, and unfortunately the missing backslash is not the cause of my problem. Thank you for your keen eyes though :)

Also, I am running an administrator account with UAC disabled, and my program has requireAdministrator set in the manifest.

However, I have noticed that both my code and yours work for simple files. After much testing, I have discovered that I only get AccessDenied messages in the following scenarios:

1: I am not the owner, and the "Take Ownership" permissions is set to Deny for e.g. Everyone.

2: I am the owner, and the "Take Ownership" permissions is set to Deny for e.g. Everyone. Curiously, in this second instance, despite the failure code, the ownership change does actually occur.

I don't see why this is happening. I, and you, have set SE_RESTORE_NAME in the process token. I should be allowed to arbitrarily set the owner SID. But it seems that I can't.

It seems that any Deny on TakeOwnership DACLs overrides my ability to take ownership. However, I can't change permissions until I can take ownership! sigh.

I might try setting SeTakeOwnershipPrivilege as you initially recommended, taking ownership to myself, changing permissions, setting ownership externally. What a pain. And I am not even very confident it will work.

I also found this: http://us.generation-nt.com/setnamedsecurityinfo-failing-rc-1307-help-59729462.html

He seems to be in a similar situation (I get 1307 if I don't set up the process token properly). But CreatePrivateObjectSecurityEx takes a whole lot more setting up.

Hmmmm. Thanks for your time.

Answer 1

The problem here is that security subsystem and model are defending the object from unreasonable ownership changes, and even having administrator permissions one needs to correctly overcome the obstacles.

There are two privileges involved in taking ownership of a file: SE_TAKE_OWNERSHIP_NAME and SE_RESTORE_NAME. The former allows taking someone's object and the latter allows setting owner who is not the setter himself.

It might look like SE_RESTORE_NAME is a more powerful privilege and is sufficient for the task, however it appears that it is not. Yes it allows to set someone's ownership, as MSDN states:

If the caller does not have the SeRestorePrivilege constant (see Privilege Constants), this SID must be contained in the caller's token, and must have the SE_GROUP_OWNER permission enabled. The SecurityInfo parameter must include the OWNER_SECURITY_INFORMATION flag. To set the owner, the caller must have WRITE_OWNER access to the object or have the SE_TAKE_OWNERSHIP_NAME privilege enabled.

However it does not let you overcome DACL item that explicitly prevents from ownership change. In this case you need that other privilege as well (that is, you need to enable both), which enables you to take ownership from someone before you decide whom you are going to give it then to.

I am copying the link to C++/ATL source code from comment above: SetFileOwner.cpp. When permissions/DACL has a Deny item, an exception takes place and enabling second privilege resolves the problem.