---
name: "dotrealm"
section: "7"
platform: "linux"
package: "thy-auth"
version: "0.3.0-1"
release: "Debian 3.1 (Sarge)"
platforms: ["linux"]
url: "https://new.carta.tech/dotrealm"
---

# dotrealm(7)

.realm-based Authoriser for Thy

## NAME

dotrealm - .realm-based Authoriser for Thy

## DESCRIPTION

**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.

## EXAMPLES

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.

## BUGS

Probably many.

## AUTHOR

Gergely Nagy \<algernon@bonehunter.rulez.org\>

## SEE ALSO

[*thy*(8)](/thy/8.md), [*thy-auth*(7)](/thy-auth/7.md)