[PATCH] s3-winbindd: Store schannel credentials in secrets.tdb
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
> > 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
> > > Also for the netr_Authenticator credential chain the logic is much
> > > 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
> > > And on the client we typically need to mutex arround network/ipc
> > > 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 http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical