[PATCH] s3-winbindd: Store schannel credentials in secrets.tdb

Christian Ambach 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
> complex
> for the clients, it's not enough to mutex the setup of the
> netlogon_creds_CredentialState,

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 mailing list