Provided by: thy-auth_0.3.0-1_i386
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
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
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:
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.
Gergely Nagy <email@example.com>