[PATCH] s3-winbindd: Store schannel credentials in secrets.tdb
ambi at samba.org
Wed Sep 26 00:30:40 MDT 2012
On 09/25/2012 10:25 PM, Stefan (metze) Metzmacher wrote:
> I have problems with the 3rd patch, because we can't hold a tdb lock
> while doing network operations! This needs to be avoided because we need to
> avoid deadlocks.
You are right. That was the reason why g_lock was implemented in such a
clumsy way: we should never hold a lock on a record while performing
operations that might potentially time out. Otherwise CTDB recoveries
might run into timeouts because CTDB cannot lock the complete database.
> I think we need a model like we have for some file server tdbs
> where we store the server_id of the process which "locks" the record,
> and use the new dbwrap_watch_record_send/recv api to wait to get the lock.
Yes, dbwrap_watch might be what we need here.
But I think ideally we would also have to convert
cm_prepare_connection() (and all the steps it takes) and other functions
like cm_connect_netlogon() to be asynchronous. I think this would help
with dealing with timeouts and where to put in appropriate mutexes. What
do you think?
> Also for the netr_Authenticator credential chain the logic is much more
> for the clients, it's not enough to mutex the setup of the
In my initial tests of the patches with a Samba member joined against a
Win2003 DC, the patch already helped: there were no more spurious access
denied messages when issueing a large amount of parallel connection
requests. So we are on the right track here.
> we also need to mutex the netlogon_creds_CredentialState->sequence etc.
> And on the client we typically need to mutex arround network/ipc operations,
> which should not be mutexed by a tdb lock.
In which cases (e.g. against which DC versions) is that mechanism used?
When certain RPC calls or validationlevels are not available? I am not
very deep into the schannel / authentication pieces, so I (and maybe
others) could use some coaching here.
More information about the samba-technical