Re: [9fans] Factotum vs SASL

[Lyndon Nerenberg <lyndon@orthanc.ca>]

> I've got the impression that there're some similarities between SASL
> (saslauthd) and Factotum - at least at the point that both are
> offloading actual authentication handshakes to a separate service.
> But I have to admit that I didn't have done a deeper analysis of
> these two.
> 
> Could anybody with deeper insight perhaps give some detailed
> comparison between them ?

No, they aren't the same thing.  saslauthd was written to provide privilege separation for the CMU IMAP server.  The CMU mail store processes (imapd, popd) would run under a unique uid, which owned all the files in the message store.  To do plaintext authentication using the UNIX /etc/passwd database, if the host used shadow password files, you had to have an effective uid of 0 to be able to read the encrypted password field.  Rather than have imapd run as root, and then drop privileges down to the mail store uid, the code requiring uid=0 was isolated into a separate process: saslauthd.  When imapd needed to do authenticate a plaintext login request against the shadow password file, it would contact saslauthd over a named socket, send it the plaintext userid and password, then wait for a pass/fail response to come back.  The protocol over the named socket is private to the Cyrus code.

So, saslauthd doesn't speak SASL, it just proxies certain system requests that require escalated security permissions to invoke.  It did grow to include a few additional mechanisms (dce, kerberos, ldap) that benefited from its ability to keep a temporary cache of valid credentials, thus reducing the number of calls out to the external services.

factotum is a different beast, best explained by the security paper: http://plan9.bell-labs.com/sys/doc/auth.pdf