On Thu, 2008-05-29 at 16:48 +0200, Dan Hor?k wrote:> Hello,
>
> I am the new maintainer of dovecot for Fedora and Red Hat and so I am
> trying to cleanup some old reported bugs. One of them is a problem when
> "deliver" writes of temporary files into /tmp are blocked by
SELinux
> policy (https://bugzilla.redhat.com/show_bug.cgi?id=424091). From the
> SELinux's point of view it is bad when system services try to write
> into /tmp (for detail see http://danwalsh.livejournal.com/11467.html).
> The solution looks simple - just to switch from /tmp to PKG_RUNDIR (line
> 472 in deliver.c for dovecot 1.0) for writing the temp files. But this
> raises two questions - will it really work and when yes, is it
> acceptable for the author?
I don't much like it writing to /tmp either, but PKG_RUNDIR won't work
either because it doesn't have write permissions there. Especially
because some people run deliver under multiple different UIDs. So it
would have to be some world-writable directory. Although one could be
created under PKG_RUNDIR (or actually base_dir setting would be better
than hardcoded PKG_RUNDIR).
It would be nice if this writing could be avoided completely. And in
some (most) situations it would be possible (although code changes
aren't that simple), but there's the problem of what to do when a 100 MB
message comes and a Sieve script requests something that requires
parsing the message body. The message body must be read through multiple
times then and the only solution is to save the message somewhere
temporarily.
I guess yet another possibility would be to initiate a saving to INBOX.
If the destination is INBOX, the only thing to do is to commit the
transaction. If the destination is elsewhere, with luck the written temp
file could be link()ed to destination (would again require non-trivial
code changes).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080529/4e952a8a/attachment-0002.bin>