After fixing some unforeseen collateral damage that crept in when we started using roles in SELinux policy, I think we've got oddjob working again and doing the right thing in F9.

The bits in the oddjob-mkhomedir package make a good example of how you can get something useful going rather easily.

Dan pointed out that having pam_oddjob_mkhomedir.so refrain from doing anything if the user's home directory exists would be less wasteful in the cases where the user doesn't need her home directory created.

It's occurred to me that while having the pam_oddjob_mkhomedir.so module make the request is okay, that it's something that could be generalized to let arbitrary things be triggered at login-time.

Then of course there's the PolicyKit integration (branch), which works, but needs to be gone over again to make sure it doesn't do anything super-dumb.

Maybe I'll propose a talk (or a lightning talk) about oddjob for FUDCon. Or else just barge into David's PolicyKit talk.

Off the top of my head, I can think of three packages which attempt to do what ssh-agent does, but which aren't ssh-agent.

Boggle boggle boggle.

The Fedora infrastructure and translation folks offered to bulk-move projects off of the CVS repository on the venerable elvis.redhat.com (also known as "rhlinux.redhat.com") to the shiny new fedorahosted.org server, so I took them up on it.

The takeaway is that oddjob, pam_krb5, pkinit-nss, setuptool, and splatbind all live in git repositories now. "Why git and not something else?" I wanted something that was distributed, and the local X guys rave about git.

This fulfills my Technotronic reference quota for the year.

Yeah, it's late. Sue me. On second thought, don't.

So I went to FUDCon. Nitin already posted his notes, which made me realize that I'd forgotten to use my camera again. I spent an inordinate amount of time getting a loaner from the office working on the wireless, so I was offline for large chunks of the weekend, which as it turned out, was fine.

I did get a bit more work done on the oddjob PolicyKit integration branch, as planned, but it's not quite where I want it to be to merge it to mainline (it's using APIs which are promised to be super-slow, which is less than optimal). As it happens, I haven't gotten back to it in the 2+ months since then.

The big event for me was the Func session. Func is made of awesome and excitement, but I had some concerns about how it used PKI. After quietly fretting about it, which I do far too much, Seth hunted me down and grilled me about it. In summary: certmaster doesn't quite do what the RFCs say a CA should do (mainly, revocation and basic constraints: in that certmaster didn't support them), and I think we generally agreed about that.

Part of this was due to not being able to create and add certain extensions to certificates via pyOpenSSL -- the code was there, but it had rotted as OpenSSL gained new APIs. A week or two later, I took another stab at it and filed a bug to at least get pyOpenSSL to provide a way to add extensions.

Ah, as Max points out, Friday's FUDCon hackfest won't be held at Red Hat's headquarters. Darn, that would have been amusing.

People seem to be noting what their plans are, so here goes: I'm probably going to Adrian's Func session, the GPG keysigning, and the Fedora Account System session.

Other than that, I expect to be hacking on the usual stuff that very few people around me are messing with (getting oddjob to be able to use PolicyKit authorization data in its ACLs, random other stuff), and just hanging around and being a nuisance.

Thought about the offline authentication problem and pam_krb5 some more. If we just let the helper contact the KDC, we double the number of round trips made between the client and the KDC unless we provide some way for the helper to pass the obtained credentials back to the calling process, which isn't good. If we don't do that, then we may cost the user in terms of failed logins, which could trigger a KDC-enforced lockout policy.

At least we've got another test release before we feature freeze for FC7, so we've got time to think about this some more.

In summary, Connectathon totally ruled.

This is a digest of some notes I've had for a while, recorded here in case someone else finds them useful. (Let me know if I'm wrong on any of this.) No, there's not really much of a point to this.

When applications on Linux systems want to get information about a user, they frequently call either getpwnam() or getpwuid(), passing in the user's name or UID, respectively. Likewise, for groups, getgrnam() and getgrgid().

When that happens, libc consults /etc/nsswitch.conf for the configuration which describes how it will answer the application's question. Absent any control flags, it will often look like this:

passwd: files hesiod nis ldap

For each module listed, libc constructs a soname (libnss_foo.so.version), uses dlopen() to load the named library, and calls into a function provided by that library. On most systems (including all of the platforms Fedora builds on), version is hard-coded to 2, but on a few, it's 1.

Exactly which function the shared library should export, and what its signature should be, varies based on which function the application actually called, but there's a pattern.

getpwnam(),getpwnam_r() → _nss_foo_getpwnam_r()

getpwuid(),getpwuid_r() → _nss_foo_getpwuid_r()

The exported functions don't return a pointer to some global result structure. Rather, they fill in a passed-in structure and return a result code. The function also gets a chunk of memory which it can use to store items of which the structure will hold a pointer (for example, all of the string members of a struct passwd).

For functions which only return one result (getpwnam, getpwuid, and so on), libc by default stops at the first function which returns a success. For enumeration functions, libc generally iterates through all of the configured modules. There's more detail in the glibc info pages, but that's the basic idea. Note that the details of how this fits together varies among libc implementations.

Building a good module can be tricky.

The calling application may be multithreaded, so your module needs to be thread-safe. But it may also not be multithreaded, so your module can't be dependent on threading functions. This isn't so difficult as it might sound because certain threading functions are also available, in no-op stub form, to non-threaded applications. So long as you limit yourself to these, you'll be fine in both cases.

pthread_mutex_lock()/pthread_mutex_unlock()

pthread_cond_init()/pthread_cond_destroy()

pthread_cond_broadcast()

pthread_cond_signal()

pthread_cond_timedwait()

pthread_cond_wait()

These days, you also have thread-local storage.

Because your module may be loaded by many, many processes (including otherwise lightweight programs such as "ls" or "find"), keep your code size and list of external dependencies small. Ideally, link to nothing other than libc itself.

One popular strategy for achieving this is to make your module a stub which contacts a local daemon, and to have that daemon do all of your heavy lifting. This is the approach being considered by at least one module named nss-mysql, and is the one used in Doug Nazar's nss_ldap2, Arthur de Jong's nss_ldapd, and (probably the best-known example) Samba's winbindd. Crutcher and I even took a stab at it a while back with splatbind.

A slightly less popular strategy is to use linker flags and static libraries to pull all of your module's dependencies into the module itself. It's what we do with nss_db in Fedora, and made far easier because upstream Berkeley DB packaging includes support for this sort of scenario.

Your module may be called while the system is not yet fully "up", and again while the system is in the midst of shutting down. If you depend on the network, keep in mind that it may not be there.

The calling application may fork() between calls into your module. You must handle this gracefully, including making sure that parent and child don't get tripped up by the fact that they're now sharing an open connection to every resource the parent used to have.

Take care that the right thing happens when the calling application calls exec(), whether or not it's preceded by fork().

If you call into libc's nsswitch subsystem (which happens most often when a library which you're using needs to resolve a hostname), and especially if you offer hostname resolution services, be mindful that you may end up inadvertently calling yourself, either directly or indirectly with the help of a daemon such as nscd.

The pkinit-nss module erroneously requires that the nonces in the request body and the pkauthenticator match. There's at least one way to embed signed data inside of enveloped data which I hadn't provided for, either.

The pkinit-nss module's error reporting doesn't encode trusted-certifiers right. Forgot to take the address of a pointer to a pointer to a struct when passing it into the encoder.

Oh, and Heimdal seems to like using AES to encrypt enveloped data.

The pkinit-nss module's CMS implementation wasn't sorting signed attributes correctly, because NSS's ASN.1 encoder is a BER encoder, and you only need to sort for DER. Oops. So feed the "unordered" data into encoder in the right order.

The pkinit-nss module wasn't supplying a list of invalid certificates if it encountered a revoked certificate.

The pkinit-nss module wasn't correctly encoding or decoding the typed-data of most errors. It wasn't correctly encoding the public numbers of the DH key agreement process correctly, either. It wasn't correctly comparing the size of the client's DH prime against the configured minimum.

Got into yet another conversation with Dan and Steve about being able to log in while offline, and I think I convinced them that naively caching whatever the user types in respones to a prompt while online, and then repeating the prompt and comparing the answer to the cached value when offline, generally doesn't work.

Why? Well for one, one-time passwords: if you cache the response, you've taken the one-time property out. For another, smart cards: if you let the user in with just the PIN (and remember, at this level you don't even know that smart cards are being used), you've just removed one factor from the two-factor authentication system.

What we hit on for Kerberos is a helper which transforms the password (not using the usual string-to-key -- storing a keytab with your keys on every system you ever type a password into would be... horrific) and stores the result as a "key" in a local keytab file if the KDC says that that's good enough. (Using the keytab manipulation facilities from libkrb5 saves us from having to implement our own file format.)

At the Kerberos level, you can have some idea if the user-response you're examining is a password or not, and whether the KDC is reachable or not, so it's tougher to do stupid things. The helper can always attempt to contact the KDC, parse the error code which is returned by libkrb5, recuse itself if a password proves insufficient, check the cache if the KDC is unreachable, and update or clear the cache entry if the KDC was able to return a response.

Anyway, that's the idea. Maybe I'll have time to code it up before the test 2 freeze.

We've started exercising the new feature in RHCS 7.2 which lets you specify a Kerberos principal name as a value for an issued certificate's subjectAlternativeName, as specified in the PKINIT RFC. (Prior to that, I'd been doing testing using principal names encoded the way Windows expects them, so I was looking forward to it.) So I handed the certificate to my parsing code, and (you guessed it) it didn't work. Grrr. Turns out I'd been using a different (and as it turns out, incorrect) decoding template than the one I was using to encode values as a sample. Luckily, fixing that was quick work.

Made some headway on semi-automating the process of generating certificates with the right values in them using OpenSSL. Need to make sure the keys and certificates can be bundled up into PKCS#12 bags, which p12util will like, before I can go much further down that road.