Bug 15303 - Can't change directory or file owner even if user has SeRestorePrivilege
Summary: Can't change directory or file owner even if user has SeRestorePrivilege
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.15.13
Hardware: All Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on:
Reported: 2023-02-08 16:25 UTC by Andrea
Modified: 2023-02-09 18:54 UTC (History)
0 users

See Also:

debug logs (2.42 MB, text/plain)
2023-02-09 08:24 UTC, Andrea
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrea 2023-02-08 16:25:21 UTC
From windows client it's not possible to change the owner of directories in Samba share, even if the user has the SeRestorePrivilege (Samba is a Domain Member).
In the Samba logs I can see the following error message:

[2023/02/06 13:23:31.624803,  3] ../../source3/modules/nfs4_acls.c:1042(smb_set_nt_acl_nfs4)
  chown New folder, 11150, 4294967295 failed. Error = NT_STATUS_INVALID_OWNER.

This points to the try_chown() in samba code, which should become root and allow the chown, if the user has the SeRestorePrivilege:

	if (lp_enable_privileges()) {
		bool has_take_ownership_priv = security_token_has_privilege(
		bool has_restore_priv = security_token_has_privilege(

		if (has_restore_priv) {
			; /* Case (2) */
		} else if (has_take_ownership_priv) {
			/* Case (3) */
			if (uid == get_current_uid(fsp->conn)) {
				gid = (gid_t)-1;
			} else {
				has_take_ownership_priv = false;

		if (has_take_ownership_priv || has_restore_priv) {
			status = NT_STATUS_OK;
			ret = SMB_VFS_FCHOWN(fsp, uid, gid);
			if (ret != 0) {
				status = map_nt_error_from_unix(errno);
			return status;

From windows I have added the SeRestorePrivilege to that user, and actually samba can see that privileges for the user:

# net rpc rights list 'DOMAIN\user' -S X.X.X.X -U Administrator

So it seems cause of a bug the privileges are not in the security token.
Actually the debug logs shows that in the security token for that user the Privileges are missing

[2023/02/08 10:06:05.624154,  5] ../../libcli/security/security_token.c:57(security_token_debug)
  Security token SIDs (13):
   Privileges (0x               0):
   Rights (0x               0):

If I use the "Administrator" user the Privileges are present in the security token:

[2023/02/08 10:49:21.253173,  5] ../../libcli/security/security_token.c:57(security_token_debug)
  Security token SIDs (25):
   Privileges (0x        1FFFFFF0):
    Privilege[  0]: SeMachineAccountPrivilege
    Privilege[  1]: SeTakeOwnershipPrivilege
    Privilege[  2]: SeBackupPrivilege
    Privilege[  3]: SeRestorePrivilege
    Privilege[  4]: SeRemoteShutdownPrivilege
    Privilege[  5]: SePrintOperatorPrivilege
    Privilege[  6]: SeAddUsersPrivilege
    Privilege[  7]: SeDiskOperatorPrivilege
    Privilege[  8]: SeSecurityPrivilege
    Privilege[  9]: SeSystemtimePrivilege
    Privilege[ 10]: SeShutdownPrivilege
    Privilege[ 11]: SeDebugPrivilege
    Privilege[ 12]: SeSystemEnvironmentPrivilege
    Privilege[ 13]: SeSystemProfilePrivilege
    Privilege[ 14]: SeProfileSingleProcessPrivilege
    Privilege[ 15]: SeIncreaseBasePriorityPrivilege
    Privilege[ 16]: SeLoadDriverPrivilege
    Privilege[ 17]: SeCreatePagefilePrivilege
    Privilege[ 18]: SeIncreaseQuotaPrivilege
    Privilege[ 19]: SeChangeNotifyPrivilege
    Privilege[ 20]: SeUndockPrivilege
Comment 1 Jeremy Allison 2023-02-08 18:47:23 UTC
Can you get me a debug level 10 trace of the user first connecting ? It's when the token is created for that logging in user that the privileges should be associated with the account, so it'd be good to see all debugs around that.
Comment 2 Jeremy Allison 2023-02-08 18:53:52 UTC
The key should be in the debug inside get_privileges_for_sids().

There is a DEBUG info here (debug level 5).

                DBG_INFO("sid = %s\nPrivilege set: 0x%"PRIx64"\n",
                         dom_sid_str_buf(&slist[i], &buf),

which should print out the hex value of any privilege set for each specific SID in the user token for the logged on user.

This is called from finalize_local_nt_token() which is called as the last act when creating a token for the logging on user.
Comment 3 Andrea 2023-02-09 08:24:03 UTC
Created attachment 17755 [details]
debug logs
Comment 4 Andrea 2023-02-09 08:27:22 UTC
I have attached debug logs (level) for the client user "andrea" that open the share "test" and try to change the owner of directory "New folder" from "andrea" to "betty"
Comment 5 Andrea 2023-02-09 08:33:19 UTC
I don't see in the log the message "Privilege set:" for the SID of "andrea" user, which is S-1-5-21-2736888305-896212807-1561745698-1142, but I do see the message:

[2023/02/09 02:20:21.493651,  4, pid=51512, effective(0, 0), real(0, 0)] ../../source3/lib/privileges.c:99(get_privileges)
  get_privileges: No privileges assigned to SID [S-1-5-21-2736888305-896212807-1561745698-1142]
Comment 6 Andrea 2023-02-09 08:47:27 UTC
the "tdbdump /var/lib/samba/account_policy.tdb" output doesn't show the SID S-1-5-21-2736888305-896212807-1561745698-1142
Comment 7 Andrea 2023-02-09 15:21:34 UTC
Also the privileges for "BUILTIN\Backup operators" are not set in the db

# net rpc rights list 'BUILTIN\Backup operators' -S -U administrator

# wbinfo -n 'BUILTIN\Backup operators'
S-1-5-32-551 SID_ALIAS (4)

# tdbdump /var/lib/samba/account_policy.tdb | grep -A1 S-1-5-32-551
key(18) = "PRIV_S-1-5-32-551\00"
data(8) = "\00\00\00\00\00\00\00\00"
Comment 8 Jeremy Allison 2023-02-09 17:22:30 UTC
Well that explains it. Now the problem is why net rpc rights set isn't setting the bit in the tdb.
Comment 9 Andrea 2023-02-09 18:13:50 UTC
As far as I can see "net rpc rights set" command just connect to Windows DC and set the privileges, it doesn't touch Samba account_policy.tdb.
Moreover, the privileges may be set directly from the windows DC, and Samba should load it even in this case.

The issue doesn't affect the Administrator user because when smbd start we have the following calls flow:

/* BUILTIN\Administrators get everything -- *always* */
grant_all_privileges( &global_sid_Builtin_Administrators )
Comment 10 Jeremy Allison 2023-02-09 18:30:48 UTC
Ah that explains it completely :-).

You need to set the rights/privilages ON THE SAMBA SERVER serving the files.

The account_policy.tdb is local to a server. Use -S <samba_server> to connect
to the correct machine.
Comment 11 Andrea 2023-02-09 18:37:33 UTC
(In reply to Jeremy Allison from comment #10)
Interesting, that way I can see the privileges for that user in account_policy.tdb.
Does that mean Samba can't load the privileges from DC (when the user open the session) and you have to add the privileges manually in the Samba server?
Comment 12 Jeremy Allison 2023-02-09 18:54:48 UTC
Yes, privileges are local to a server, not global via a DC.

What people usually do is create a group, "restore_operators" or whatever, assign users into that group in AD, then add the privilege SeRestore to that group and replicate the account_policy db to all servers that need it.