SMB server is too strict about security descriptors
SMB allows a user to 'remove' an ACL by specifying that it wants the acl to change (SMB_DACL/SACL_SECINFO), but marking that ACL as absent ((sd->sd_control & SE_DACL/SACL_PRESENT) == 0). The server incorrectly requires that the DACL/SACL be present if it is marked in the SECINFO. This can cause operations (like restore operations) to fail if the operation tries to remove one of the ACLs.
Steps to Reproduce:
create a file (i.e. "sacl-text.txt")
Then, using samba's smbcacls:
smbcacls -U <admin-user>%<password> --set-security-info=9 -C <user> //<server>/<share> "sacl-test.txt"
This sets the Owner to <user>, and sets the SACL to NULL (not present).
Command is successful.
server returns NT_STATUS_INVALID_ACL
Tested by running reproduction steps (and verifying that the command succeeds), and verified that inheritance over SMB continues to work correctly (by creating a variety of inheritable allow/audit entries on a directory, then creating a file/directory there over SMB, and verifying the inherited entries)
Updated by Electric Monk over 1 year ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit d11e14a72ad0bfccf84405261d5d93e6eaafe6a7 Author: Matt Barden <email@example.com> Date: 2020-09-01T15:13:21.000Z 13047 SMB server is too strict about security descriptors Reviewed by: Dan McDonald <firstname.lastname@example.org> Approved by: Robert Mustacchi <email@example.com>