This project is my current solution to provide a "simple" user management interface through Samba for our clients' servers.

The motivating example is this: we provide Linux servers to our clients (thereafter written Cs), and need to provide them a way to manage FTP directories for their own clients (the clients' clients, CCs). The Cs know nothing of Unix administration.

At first, the best I could do was to create a rwx--x--x directory and tell the Cs to put "obfuscated" directories in it, the name of which they could then give to the corresponding CC. The anonymous login was used, and "security" was provided by the fact that the root directory was unreadable by the CCs.
It was easy for the Cs. All they had to do was to enter the root FTP directory through their Samba access, create a new directory for a new CC or remove it when no longer needed.
Alas, the CCs were having trouble with that. Many FTP clients (or their user) seemed to have difficulties accessing those "hidden" directories. The Cs, tired of having to respond to countless help requests came back to us and asked for a solution.

At that point, I was sure of a few things:

• The system should stay the same for the Cs. The idea (thereafter userdirs) of keeping both the user directories and the credentials in one place was a good one.
• The system should be as standard as possible for the CCs. No hidden directories, just a login and a password.
• I should not modify the FTP server's source code. Userdirs could be adapted to other services (like mailboxes) and as such, should not be integrated "inside" the FTP server. And because no such patch would be accepted in any sane FTP server distibution (much less vsftpd, which I use), I would need to maintain a private branch. And that's hell.
• The user-set corresponding to the CCs should be in a "virtual domain". They should not be global Unix users. For example, they could exist only in the context of the FTP server.

With that in mind, it seemed clear that I needed to create a piece of library that would be given credentials by the FTP server and would respond with a user directory, if authentication was sucessful. In order to avoid having to modify the server's code, the library should be accessed through a supported, standard interface. I had heard that this was what PAM (the Pluggable Authentication Modules infrastructure) was all about, so I imagined this scheme: write a PAM module, tell vsftpd to use it for authentication and Voilà! I had my userdirs implementation. Small, clean... in a word, beautiful.

But life being what it is, I soon discovered the horrific truth: PAM doesn't know anything about the home directories of users! All PAM-compliant applications now use PAM instead of the libc authentication functions, but once a user is authentified, they still rely on the old getpwnam() libc function to get the home directory, and that call navigates way around PAM directly to the /etc/passwd file (/etc/nsswitch.conf notwithstanding).

So the beautiful PAM module became a hybrid LD_PRELOAD hack to intercept the getpwnam() calls. It works, but it's ugly. But it works.

Right now, it works with:

• vsftpd
• exim4
• courier