dotrealm - .realm-based Authoriser for Thy

dotrealm is a so-called Authoriser for the Thy HTTP daemon. It is spawned by the master daemon process, and they communicate via a pipe.

This is the most simple (but usable) authoriser so far. Whenever Thy encounters a .realm file in a directory, she asks the authoriser process (in this case, dotrealm) to determine what the realm is, and later on, asks again to authorise a user, with a given password.

This authoriser utilises PAM, putting the hard work on its shoulders.

The authorisation process works like this: Thy encounters a .realm file in a directory, and talks a bit with the authoriser to figure out the realm, then passes back a username, a password, and the name of the realm. The authoriser then appends a @ and realm to the username, and passes it on to PAM. It uses thy as the service name.

Let's make it clearer with an example! Say, we have a realm, Kitty (putting the string Kitty into /var/www/kitties/.realm will accomplish this. Everything under /kitties/ will be under the Kitty domain), and a client request the URI /kitties/kitten01.jpg, with the username of Catwoman and the password Jaguar24. The authoriser will send the username Catwoman@Kitty to PAM. The password will not be altered.

One drawback of this method is, that one has to remember to create accounts with the realm appended. However, with most of the PAM modules which will be used with this authoriser, this shouldn't be much problem.

Lets put together a complete realm!

Suppose we do not have virtual hosts enabled, and assume that the document root is /var/www. We want to restrict access to the /dirty-secrets hierarchy, so we put a .realm file there, containing the text Secrets.

Then, we need to set up PAM, to correctly handle the Secrets realm. Users in the realm need not to have anything to do with system users. I'd even advise that if a user in the realm also has a normal account, the passwords be different.

A sample /etc/pam.d/thy file is given below:

auth    sufficient      pam_pwdfile.so pwdfile=/etc/thy/realms/Secrets
auth    required        pam_deny.so
account required        pam_permit.so
session required        pam_permit.so

The /etc/thy/realms/Secrets file could look like this:

john@Secrets:U73bQgFXUJgrQ
debbie@Secrets:$1$RGrVf.CF$jiA/ls/dyK9COy7HYoW.r0

Notice that the first password is DES-encrypted, and the second is an MD5 sum. In general, one needs to store the passwords in encrypted form. There are many tools to encrypt a password, one of them is perl. You can generate DES-encrypted passwords like this:

perl -e 'print crypt ("password", "salt") . "\n";'

In the above example, salt is a string of two random characters, and password is the password to encrypt.

Probably many.

Gergely Nagy <algernon@bonehunter.rulez.org>

thy(8), thy-auth(7)