Index: [thread] [date] [subject] [author]
  From: David Harris <>
  To  : <>
  Date: Tue, 11 Jan 2000 22:00:26 -0500

[background05] Alex Howansky getwpman replacement 1 of 3

I ran into a guy that created a getpwman replacement patch for uwimap and
shared my concerns. He then tested his code and found a security hole, which
he fixed. This verified my suspicions.

This e-mail is first contact. I present my suspicions.

 - David Harris
   Principal Engineer, DRH Internet Services

-----Original Message-----
From:	David Harris []
Sent:	Tuesday, December 28, 1999 6:33 PM
Subject:	RE: [imp] UW-IMAP patch to allow virtual users

Alex Howansky [] wrote:
> I've just finalized my patches for UW-IMAP that enable it to authenticate
> against a PostgreSQL database. This allows having email accounts without
> system accounts. You can download the patch from:

This patch may be flawed. I've talked to other people who hacked together a
getpwnam replacement for UW-IMAP and I think there is a basic design flaw
with this kind of system. You see, normally users are protected from reading
each other's e-mail by UNIX file permissions. When you dump a whole bunch of
users under one UID, you need to have the IMAP server enfoce the
restrictions. A user could provide a ".." in their mailbox path to see
another virtual user's e-mail. The way around this is to properly hack the
env_unix.c file so that for virtual users like this the blackBox flag
preventing users from backing out of their mail directories.

getpwnam hacks like this also have problems when you try to use imap-utils
programs such as dmail.

Let me quote from an e-mail I sent to another getpwnam hack author.

------- begin quoted e-mail -------

> This patch has nothing to do with blackbox, I've never tried to limit the
> ".."'s however this is purely a fdiffrent mechinisim to get user/pass's
> of the "/etc/passwd" (in this case being done in Postgresql)

Blackbox as it was originally written was just a way of saying "this user
may not access files outside of a specific directory"... it was designed for
systems that has a NFS /var/spool/mail or home directories. There was then a
"blackbox" directory, say "/mnt1/mail" and each user had their own directory
inside of that, say, "/mnt1/mail/$USER". They were not allowed to access any
e-mail outside of this directory (even in their home directory) because it
might now be NFS safe.

I'm not using this feature of blackbox. I'm just using blackBox flag to make
c-client be strict an not allow them to access e-mail outside of their home

With your system, the blackBox flag is not set, so users are allowed to
specify ".." in their mailbox names. This means that if you are running
multiple e-mail users inside of one UID, they can all read each other's

I urge you to simply TRY breaking down the security walls this way. Assume
you have two e-mial users running as the same uid with the directories
"/mnt1/mail/usera" and "/mnt2/mail/userb". Assume that userb had a folder
named "folderb".. try logging in as usera, and then getting the mailbox
"../userb/folderb". From my source code understanding, I expect that this
will work and user a can read userb's e-mail.

------- end quoted e-mail -------

The person to whom I wrote this e-mail never replied telling me if their
system was secure to my proposed attack.

I have my own very specific hack/virtual-user-authentication-interface that
I talked about a bit on the Qmail list. (The UW-IMAP code was so weird that
it took a few days for me to figure out how to do it securely.) What I have
is a very nice hack to UW-IMAP which creates a specific interface for
virtual user authentication and my own very site specific backend
authentication code. I need to write a few generic backends before I release
the code, I expect.

See my interface description here:

However, I've just been too busy to get anything out.

Alex, could your Postgres backend be integrated to use the vpop__userauthen
interface? If so we could perhaps get my patch out the door and into
production. You write the Postrges backend and I can write a
DB_File/flat-file backend, perhaps. What do you think?

 - David Harris
   Principal Engineer, DRH Internet Services

Index: [thread] [date] [subject] [author]