Re: [exim] MBX format and UW-IMAP

Hello Philip,

> This issue has arrived at the top of my "investigate" list. Now that I
> read it again, I am confused. Exim should create the lock file owned by
> the end user, not by exim. The transport is running as the end user, so
> it cannot do anything else.
>
> Unless ... you are using an unusual configuration. What is the
> configuration of the appendfile transport that gives this problem? Are
> you running the transport as exim for some reason?

Not as such, but the mailbox is owned by user "exim", so would that
explain it?

The intention is to create a shared mailbox, and so it relies on
using the group permissions to control read/write access. Hence the
actual owner of the file is not that important, so I just happened to
make it owned by "exim".

I suppose the issue here is that the mailbox itself is group readable
and writeable, but the lockfile in /tmp isn't, and this will be the case
whichever user owns the mailbox (and hence the lockfile).

I couldn't see any way around this other than broadening the permissions
set when Exim creates the lockfile in /tmp. I suppose 0660 would have
sufficed, but I used 0666 because that is what UW-IMAP seems to do.
I suppose that technically this could permit a DoS attack - someone
else could have a process that opens the lockfile and obtains an
exclusive lock on it, but in our case the server is not one that users
can log in to, so I'm not too worried about that.

However, as a general principle I can see why it is a good idea
to make the lockfiles mode 0600. Might it be possible to have some
way of indicating that an MBX mailbox is intended to be shared so that
it can set different permissions on the lockfile than for non-shared
mailboxes?

For information, here is the transport I am using:

sharedbox_delivery:
driver = appendfile
mbx_format = true
message_prefix =
message_suffix =
file = /spool/mail/shared/${local_part}/${substr_8:${local_part_suffix}}
envelope_to_add
return_path_add
mode = 0660
mode_fail_narrower = false


Regards,

Dave Snowden
Dept. of Computer Science
University of York