Discovered by Andreas Schneider <asn@samba.org>. Caused by commit c0e7f7ff, by Jerry Carter, which explicitly changed : access_check_samr_object() - *acc_granted |= saved_mask; + *acc_granted |= rights_mask; This means that *any* NT_STATUS_OK return from access_check_samr_object() will add in the "extra" bits, even if not asked for. This has the effect of changing a read-only handle into a writable one giving SAMR_DOMAIN_ACCESS_CREATE_USER on any open. Note - this bug goes all the way back to 3.2.0 (although not in 3.0.x). Once we have decided on a fix I'll create back-ported patches for all versions. Two possible patches for master will follow. Jeremy.
Created attachment 6975 [details] Patch #1 This is the patch for master if we must always return the SAMR_DOMAIN_ACCESS_CREATE_USER for any handle with SEC_PRIV_MACHINE_ACCOUNT, SEC_PRIV_ADD_USERS privilege.
Created attachment 6976 [details] Possible patch #2 This is the patch to use if we don't add the SAMR_DOMAIN_ACCESS_CREATE_USER to open handle requests for users with SEC_PRIV_MACHINE_ACCOUNT, SEC_PRIV_ADD_USERS privilege.
Comment on attachment 6976 [details] Possible patch #2 With this one, root would not get rights_mask
Comment on attachment 6975 [details] Patch #1 I think I'd preferr this one
Phew - not a security issue (so unlocking from Samba Team only). We have protections inside _samr_CreateUser2() that also check for the privileges, so even though the handle returned has that permission, we check again. Still going to fix this in 3.6.1 though. Jeremy.
Lowering importance and severity.
Created attachment 6981 [details] git-am fix for 3.6.1. Patch that went into master.
Comment on attachment 6981 [details] git-am fix for 3.6.1. Looks good
Karolin, please pick for the release
Pushed to v3-6-test. Closing out bug report. Thanks!