Provided by: thy-auth_0.3.0-1_i386 bug

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-auth(7)