Subject: imap and virtual domains in RedHat 6.0 and 6.1

From: Patrik Hall <[email-masked]>
Date: Wed, 13 Oct 1999 17:19:40 +0300 (EEST)

I have been using RedHat distribution now for some time and I have noticed
some functions in a program called linuxconf bundled with the
distribution.

linuxconf is a admin utility where network parameters, user accounts, etc.
can be tuned in X/gnome/text-environment, administration can even be dome
over http.

It also has support for virtual domains and is capable to roll a new
sendmail.cf based on new settings and restart sendmail. I can then add
"pop-users" for that domain. Incloming mail is stored in
/var/spool/vmail/domain.com/mailbox and passwd/shadowfile/aliases are
stored in /etc/vmail/domain.com/ directory. Passwords are allways stored
with crypt-encryption no matter what the rest of the system uses.

Bundled with linuxconf is a small pop-daemon that supports pop-access to
theese mailboxes in that matter that depending on the ip the connection is
made it figures out what domain it should use. This means that each domain
must have its own ip. 

I have made a dirty hack so that c-client supports this in some way. I
decided that if the user enters "[email-masked]" as username, or
"user#domain.com" for netscape compability, domain.com is selected as
domain. If no domain is specified, standard behaviour is applied. Aliases
are also parsed so "[email-masked]" is mapped to username if
alias is found and it is local and no list. Hope it works.

If anybody is interrested in this, the source and rpms/srpms/patches can
be found at

http://phall.kdsoft.fi/~phall/vimap/

The most work is done in src/osdep/unix/env_unix.c

I have added some functions that replaces getpwent, getpwnam and checkpw
with corresponding functions with virtual behaviour. 

Please somebody, if anybody have time, check and test my code, awful
things like vsplitline in my code can definitly be improved.

Have a nice day.

---
   Patrik Hall <[email-masked]> - +358 50 500 4668 - ICQ# 13414838

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Wed, 13 Oct 1999 08:52:05 -0700 (PDT)

> with corresponding functions with virtual behaviour.

For what it's worth, here's something that you should check:

imapd's and ipop2d's security model is based entirely upon the filesystem
security model.  Therefore, it is essential that any login do a proper
setuid()/setgid()/initgroups() to unique UID/GID settings for that user.  If
[email-masked] and [email-masked] are both hosted on the same machine and have the
same UID, then fred can get at joe's mail (and vice versa).

This is less of a problem with ipop3d, since POP3 only allows access to INBOX,
but failure to do this properly can be disasterous with protocols such as POP2
and IMAP which allow secondary folders.

---

From: Patrik Hall <[email-masked]>
Date: Thu, 14 Oct 1999 14:41:37 +0300 (EEST)

> and IMAP which allow secondary folders.

linuxconf generates an unique UID for every user. It is possible to
specify for each domain a UID region, i.e domain1.com UID region starts at
61000, domain2.com at 62000 etc. The linuxconf passwd/shadow files are
nothing more than /etc/passwd and /etc/shadow extensions. Theese files
contains all necessary info for us. We need only new getpwent, getpwnam,
getpwuid etc. to parse theese new files. UID is still hopefully unique
even if the user database is scatterd in many places. Functions like
getpwuid can be nasty to implement. It is not implemented in my hack
however.

Theese linuxconf passwd files look like this:
---
ben:x:21000:231:Sample User 1:/vhome/domain.com/home/ben:/bin/false
joe:x:21001:231:Sample User 2:/vhome/domain.com/home/joe:/bin/false
me:x:21002:231:Sample User 3:/vhome/domain.com/home/me:/bin/false
you:21003:231:Sample User 4:/vhome/domain.com/home/you:/bin/false
---

The directories below /vhome/domain.com/home all have corresponding uid
and permissions set to 0700, so security in my opinion is ok.

Linuxconf homepage is available at:
http://www.solucorp.qc.ca/linuxconf/

Additional information about linuxconf virtual domains is available here:
http://phall.kdsoft.fi/~phall/vimap/vdomain.txt