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

Andrew Bartlett abartlet at samba.org
Wed Oct 3 19:46:54 MDT 2012

On Wed, 2012-09-26 at 10:12 -0700, Christof Schmitt wrote:
> Christian Ambach <ambi at samba.org> wrote on 09/25/2012 11:30:40 PM:
> > 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.
> I am all for doing the change the direct way, but this sounds much
> more involved than my previous attempts. Can someone explain how
> dbwrap_watch works and what is the best way to guarantee exclusive
> access to the credentials record?
> > 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?
> Is this a requirement for exclusive access to the credentials record
> during the schannel authentication, or is this another
> improvement/simplification?
> > > 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.
> I would also need some advice how to proceed here: The sequence number
> seems to get updated in libcli/auth/credentials.c. Would this require
> locking the record, and updating it for every sequence number update?
> This might become complicated since we need to open the tdb in winbind
> and then pass the tdb handle to the correct place for those updates.

However you do it, you do need to serialise the sequence number updates
for send, but a restructure may avoid you needing to serialise the whole
request/reply chain.  Essentially, we both probably need to read up the
docs, and see if instead we can store an expected reply for a given
sequence number.  That would avoid needing to lock over the network ops
waiting for the reply. 

Andrew Bartlett

Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

More information about the samba-technical mailing list