Hosting Virtual Users

Normally, a user is someone listed in the system's database file etc/passwd. There is no need for a flesh-and-bone user equipped with a password and ready to log in. Many users listed in the system database are simply immaterial daemon users, like mysql, listed for the operating system to be able to assign a name (especially a UID in the form of a number) to a running process.

But at least these daemon users own processes, i.e. the mysql database server, and of course, real objects like files and directories are owned by those users. In a well run environment these users do not have a password, so their account cannot be abused by somebody else, and almost always the shell that would be started if someone could log into this account is the binary /sbin/nologin, which does exactly what's written on the tin, denying login.

img3.jpg And then there is another breed of users that seem to be ordinary fellows in the system and still do not exist as a user in the normal sense. These virtual users do have the ability to run certain programs, they all have a mailbox in which their private messages arrive and they all need a password to access their home directory, in which all their assets are being stored, but strangely enough there is no trace of them in the system's user base and password file.

One can argue that because the virtual users don't have a valid number (UID) they are no users, and in a strict sense this is certainly true.

But how can they own files and use a mailbox, just like other users do?

Hunting down the virtual users

We all know that in order to have a mailbox, there has to be a mailbox file (usually in /var/spool/mail) that is owned by the user respectively. And if someone is attempting to read this mailbox, there has to be some kind of authentication, so the password must be stored somewhere. At this point a real (daemon) user comes into play, the postman Tom, who of course has a valid UID listed in the file /etc/passwd, which is in fact 555 on my system.

Tom works at the heart of the mail delivery process, managing the virtual user's home directories and their mailboxes, and he is the only real user necessary to serve hundreds of virtual users on the system.

Virtual home directories and mailboxes

For every virtual user Tom creates a home directory that is used by IMAP to store the virtual user's inbox and various index and logfiles individually.

-bash-3.2# ls -laR /kx/dovecot/home
total 16
drwx------ 4 postman root 4096 Nov 16 16:56 .
drwxr-xr-x 5 root root 4096 Dec 1 15:10 ..
drwx------ 3 postman postman 4096 Nov 16 15:41 alice
drwx------ 3 postman postman 4096 Nov 16 15:19 ron
...
/kx/dovecot/home/alice/mail:
total 24
drwx------ 3 postman postman 4096 Nov 16 15:44 .
drwx------ 3 postman postman 4096 Nov 16 15:41 ..
drwx------ 4 postman postman 4096 Nov 16 15:44 .imap
-rw------- 1 postman postman 10 Nov 16 15:44 .subscriptions
-rw------- 1 postman postman 5318 Dec 11 18:34 sent-mail

All these files have been created by Tom for each of the virtual users. In order to provide this infrastructure, we have to make sure that Tom is able to use the virtual user's password when needed, and most importantly to handle the authentication process for them as well. The following lines of code show how the configuration of DOVECOT has to be changed for Virtual Domains.

##### VIRTUAL DOMAIN USERS #######
mail_location = mbox:~/mail:INBOX=/kx/dovecot/mail/%n
auth default {
  userdb static {
   args = uid=postman gid=postman home=/kx/dovecot/home/%n
  }

  passdb passwd-file {
   args = /kx/horde/htpasswd
  }
  user = apache
}

All passwords are stored in the file /kx/horde/htpasswd in the usual way required by the apache web server. This is important for two reasons, because the dovecot process can use this file to authenticate virtual users by changing permissions to apache for authentication, and simultaneously this file allows other web-based software to access the virtual user's homes with the same password. We will have a look at this later.

ron:hLILWelxS7E82
alice:ildPSIfh7EkT2

Getting all email in the right direction

By now we have managed to install mailbox access for virtual users via IMAP without the need of registration of all these users in the system's database. What we do not have in place is a mechanism to fill up the virtual user's mailboxes with incoming mail.

As you may suspect another important part of the mail delivery process has to be adjusted to ensure that the virtual users who can have totally different email-addresses will receive their mail without hassle. This time we need to add a few lines to the POSTFIX configuration file and we have to create a mapping between the email addresses and the (real) virtual users, who are supposed to read the mail.

virtual_mailbox_domains = linux-in-business.com, somedomain.ie
virtual_mailbox_base = /kx/dovecot/mail
virtual_mailbox_maps = hash:/kx/dovecot/virtual_mailbox_map
virtual_uid_maps = static:555
virtual_gid_maps = static:555

The pivotal point here is the text file "kx/dovecot/virtual_mailbox_map" in which each email address is followed by the virtual user's name. But before postfix can use this database to deliver mail it has to be hashed, i.e converted into a database file "kx/dovecot/virtual_mailbox_map.db" with the postmap command below.

ron@linux-in-business.com ron
alice@somedomain.ie alice

/usr/sbin/postmap /kx/dovecot/virtual_mailbox_map

Extending our infrastructure

The most important benefit of this system is not to have virtual users in the system's user database and being able to treat them as ordinary users at the same time. As some users tend to choose a weak password this will help to limit the damage that can be done to the system considerably. But once virtual users are established with an email address and password in the manner I have described, it seems to be an obvious idea to use these credentials for another purpose, to organise a file system-like structure for virtual users, to store their data as well. Fortunately such a file storage can be easily set up using the HORDE framework, and in particular the gollem module, that can be configured to use the file system or a MySQL database to store the virtual user's files while making them available for upload and download via a browser-enabled interface.