[Vmail-discuss] Webmail for vmail-sql
Wed, 29 Aug 2001 10:38:53 +0100
On Wed, Aug 29, 2001 at 10:07:05AM +0100, Paul Warren wrote:
> On Wed, Aug 29, 2001 at 09:59:42AM +0200, Marcin Sochacki wrote:
> [virtual webmail]
> > P.S. Chris and The Team: how about hacking some IMAP
> > server to support Vmail-SQL authentication?
> Whilst this would undoubtedly be a nice endpoint, getting there is not -
> the wu-imapd code is (according to Chris) pretty horrid.
It's foul and deranged. Also, I have not looked in detail
at how the authentication bits work, so I don't know how
easy it would be to put in the authentication code and
force it to then use a specific set of mail folders.
> > Folders should be no problem
> > IMHO, one could use e.g. $MAILBOX_PATH.$FOLDER_NAME
> > (/var/mail/SERVERS/example.com/luser.my_folder).
> That's one way of doing it, although we then have to be careful about
> '.' in folder names, and what do we do about nested folders? Another
> problem about hacking this support into an existing daemon is that we're
> asking for security that almost certainly was not designed into it,
> specifically it needs to be impossible for one user to read another
> user's mail spool despite the fact that they are owned by the same UNIX
Yeah. The nested folders problem is easily solved by
escaping; the others are not. I believe that the WU people
have asserted that they do not very much care about
security holes which allow people to get a shell after
authentication (i.e. once the daemon is running as a
normal user), which is OK where all users have shells,
pretty poor when not, and obviously disastrous if numerous
UNIX users share mailspools.
Now, arguably, we don't care very much about exploits
being constructed to take advantage of the server, but
it's obviously vitally important that users can't just
select each others' mailspools. That's an easier problem,
[Thinks....] This particular security problem is easy to
solve if we require that user email@example.com's mail goes
in the directory /var/spool/mail/SERVERS/example.com/foo/;
then we can (modulo some subtleties) use chroot and
assume, pretty much, that everything will be safe. (It's
easy to break out of a chroot if you are the superuser,
hard otherwise.) But this is wildly ugly.
Chris Lightfoot -- www.ex-parrot.com/~chris/
... If there were no witches, human testimony
and human reason are alike destitute (Bierce)