Nelson, thanks so much for the response, that was really great information. Just to shed some more light on what we're doing, we have a library that any app can use to connect to our LDAP servers securely. Each user has their own cert8, key3, and secmod databases in a private directory in $HOME. This is where our LDAP library searches for credentials when it sets up the SSL connection and SASL authentication.
You made a really good point about multiple clients using the database at the same time -- eventhough each user on the system has their own certs, they are likely to be running multiple apps simultaneously (all using the same database), and indeed some of our SW is run 24x7. So I'm thinking now that a simple NSS_Shutdown will fail The reason we need to change certs "on the fly" is because we have system requirements saying that passwords and credentials must be renewed every 90 days. So user passwords and their LDAP certs are subject to this. Now, I don't know if the expiration is enforced inside the certificate, I'd have to ask our Unix folks. What I do know is that it's a possibility, and in fact very likely right now, they will run a script to generate the new cert for a user when the old one expires. And as I said, many our apps are wither 24x7 or highly critical and cannot be brought down when they replace the certs. What's interesting to note in all of this is that it's only a problem when DS closes the connection and the app tries to rebind. For example, because we have so many apps and users running simultaneously, and because software can be running a very long time, our DS closes inactive connections after 90 seconds. So I ran two tests. First, I have a test driver that connects and adds an entry, sleeps 100 seconds, then deletes the entry and exits. I had one of our Unix guys recreate the certs during the sleep, so when the app tried to delete the entry, it saw the connection was closed and tried to rebind, and that's when I got INVALID_CREDENTIALS. Next I changed the sleep to 30 seconds, and again re-created the certs during this sleep. This time the app tried to delete entry and the connection was not closed, so it proceeded normally -- eventhough it's credentials we're technically invalid. Not sure if this is intended behavior or a bug, but it's definitely interesting. I think you're third suggestion, creating a new cert and key db and then doing a phased migration, is probably the most feasible. We could maybe setup some logic where if sasl_bind returns INVALID_CREDENTIALS, we try again with the "second" cert and key database. When these become invalid, we switch back to the original. In a sense, we just rotate between two sets of databases, where one always has the most recent (and valid) credentials. Or perhaps we could utilize the prefix for the databases to just keep creating new ones. But really I think the most plausible solution for us, given how our apps run and the amount of effort it could take to implement any sort of multiple database scheme, may very well be changing requirements for how often our certs expire. Anton - when you say submit a bug, I assume you mean against mozilla ldap (or NSS) using bugzilla? I remember in the past our Unix guys have gone through our own Sun support to report bugs, but those are usually related specifically to DS. I can do either. Mike Anton Bobrov wrote: > > NSS_Shutdown returns a value indicating success for failure. It can fail. > > libldap *may* be holding references to NSS objects when you try to shutdown > > NSS. In general, I would not expect that you will be able to shutdown NSS > > underneath libldap, without the awareness and participation of libldap. > > IMO, your best bet to to get libldap to shut down everything it knows about > > NSS and then shut down NSS. > > Mike, i think Nelson is right here. it appears that we dont do necessary > cleanup within libssldap in order for what i suggested to work. i might > have been dreaming about this but somehow i thought that approach used > to work, maybe old NSS version/s were less strict on this, dunno. anyway > i did test this and you will always get SEC_ERROR_BUSY from NSS_Shutdown > right now. there is no public api available in libssldap today you can > call for cleanup before calling NSS_Shutdown. please open a bug for this > because i think there is need for sucha cleanup api OR perhaps we can > utilize NSS_RegisterShutdown so it will call our cleanup handler before > NSS shutdown and take the burden off users. > > > The only issue I see with that approach is that libldap appears to open > > the cert DB read-only. In order to be able to update it from your program, > > you'd have to open it read-write. That's feasible. I would be cleanest > > if libldap was extended to do that, but you could do it yourself, with > > your own alternative implementation of ldapssl_clientauth_init(). > > i think you can actually call NSS_Initialize() RW from within your app > then call ldapssl functions as before and since NSS will be already in > initialized state all subsequent init attempts from ldapssl functions > will be essentially no ops. > > back to your original question and problem at hand i dont see any easy > workaround for this unless maybe Nelson can suggest some hack to force > NSS to shutdown which isnt right and probably pretty unsafe but if you > are desperate for some kinda workaround that might be it. apart from > that the only thing i can think of is doing fork() and doing ldapssl_* > reinit in the child process while making the parent quit. _______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
