Oh, how I hate armchair legal advice. You know, statements which begin with "I'm not a lawyer, but...". Please, if you see this lead-in, press your Delete key as quickly as you can and disavow any knowledge of what was written after.

I'm not a doctor, but I'm pretty sure a human being should be able to live a full and healthy life without a functioning cerebral cortex.

So e2fsprogs's copy of libcom_err isn't quite as smart as the one included with krb5, the effect being that it can't distinguish between error tables which were added to the table list using add_error_table() and tables which were added using initialize_XXX_table(), the latter of which doesn't allocate a list node off of the heap. So along comes remove_error_table(), which attempts to free() a structure which is in the data segment, and glibc laughs at you.

Still trying to scope down a useful talk to give at the Summit. Maybe I can work beads ("BEADS!") into the talk somehow. The Summit's in New Orleans, after all.

Working on getting krb5 1.4 packages put together for Raw Hide. Looks like there's a weird interaction between the libcom_err from e2fsprogs and the new shared library init/fini stuff which is triggered by pam_krb5. Oh joy, oh rapture. Oh how I wish I'd tested the krb5 betas more thoroughly.

Boston University, the folks who are kindly hosting FUDCon, is way south. Somehow I've ended up working the registration desk for the day. Oh well, at least I can do some reading and try to get some workish things done.

Got to meet a couple of the Samba developers today at LinuxWorld. And they remember me. And they don't seem to think I'm an idiot. Spent the day wandering between talks and the Fedora booth.

Most of the folks from the Westford office are going to be at LinuxWorld this week, and at FUDCon on Friday. Meantime, my cable modem's down, so I'm pretty much unable to check my email. Not looking forward to the pile which will be awaiting when I get back to the office.

With the one-year lease on my current apartment rapidly coming to its end, I've spent most of the weekend packing up various belongings into tidy boxes. (The original plan was to go all-out with nothing but packing and cleaning, but I only got part of the way through the packing, and didn't even start on the cleaning.)

Along with that snarl of cables which invariably finds its way to the space behind a computer, I packed up my cable modem. Oops, there goes my network access. Which is going to make it hard to make good on some commitments I made for the weekend.

The stickiness in the car's gear shifter finally got to the point where my pincer-like grip wasn't able to overpower it. So I've got a car which starts, warms up, heats up the passenger cabin, and won't budge out of Park.

This, on Thursday night, when it's snowing.

It's a long story, but a safety interlock was to blame. The short-term solution: remove it. Oh, the part is on order, but until then, I could spend my time idling, shifting from Park to Neutral and back. You'd never know. I'm unpredictable that way.

The places where nss_ldap uses sync APIs are mainly confined to the netgroups functionality, but a bigger problem is that it blocks in SSL_connect() when starting up ldaps (LDAP over SSL) connections. But that's not quite the same problem. This is one of those situations where having nss_ldap do all of its work out-of-process would have made the problem case far simpler to work around.

Starting from a customer query, I looked more closely at nss_ldap's timeouts than I ever have before, and confirmed their assertion that it would block "forever" if you sent a SIGSTOP to the server. The client would connect at the TCP level, but its queries would go unanswered. Maybe at some point it would get a SIGPIPE, but I didn't check on that.

Turns out that while for the most part, nss_ldap uses asynchronous APIs which let it apply timeouts, in a couple of places it uses the synchrounous APIs, which wait indefinitely for responses from the server. And if those responses never come, we have a problem.

One of these was due to a limitation in libldap, which after a brief discussion, the OpenLDAP folks quite kindly implemented for future releases. The rest, well, is going to require a patch.

Somebody asked me today about comments in the pam_krb5 sources which indicate that refreshing credentials isn't be implemented because I don't have a good way to determine when it's safe to refresh them. At the least, it would include

• the process is neither setuid nor setgid
• SUDO_COMMAND isn't set (no "sudo su" wackiness, please)
• if KRB5CCNAME is set, it points to a real file which is owned and writable by the current UID, and not world writable
• the default principal in KRB5CCNAME is the principal which we're authenticating
• if KRBTKFILE is set, it points to a real file which is owned and writable by the current UID, and not world writable
• the default principal in is the principal which we're authenticating

Though I'm still not completely sure that's enough to guarantee safety.