Temp files cleanup?

[Glenn Park]

On Sat, Nov 24, 2012 at 4:50 PM, Noel Jones <njones at megan.vbhcs.org> wrote:
> On 11/24/2012 6:19 PM, Glenn Park wrote:
>> On Sat, Nov 24, 2012 at 3:49 PM, Noel Jones <njones at megan.vbhcs.org> wrote:
>>> On 11/24/2012 4:55 PM, Glenn Park wrote:
>>>> Hello,
>>>>
>>>> Testing a new system (Debian-installed amavis), I see that files in
>>>> /var/lib/amavis/tmp are left hanging around.  Presumably a cron job
>>>> was installed with amavis that cleans these out, BUT is there a reason
>>>> amavis doesn't delete the unpackaged messages when it's done with
>>>> them?
>>>
>>> The email.txt and parts directory are intentionally left intact so
>>> the filesystem doesn't waste the time to recreate them for each
>>> message.
>>
>> I don't follow - email.txt appears to be the content of each message.
>> What would be recreated if each message gets its own email.txt?
>
> The file is left intact, and the contents is replaced with the next
> message.  This eliminates an expensive metadata operation.
>
> Please refer to the performance section of the amavisd-new website.

I see. My misunderstanding based on testing with just a few messages.
I see now that the email.txt file does get updated with new message
content as new messages are handled by the same worker thread. The
explanation that was helpful for me is here:

http://www.ijs.si/software/amavisd/#faq   (scroll to "Tips and FAQ -- general")

>>> The parts directory will normally be empty when amavisd is idle, but
>>> will have leftover files if there is a problem.  These files are not
>>> cleaned automatically, as they may need to be examined for problem
>>> solving.
>>
>> OK, so the issue (or my misunderstanding) is with only email.txt
>>
>>> These files and directories are security sensitive *must not* be
>>> world-readable since mail in transit is processed here.
>>
>> That's exactly why I am concerned.  I'll have to find another TMPFS
>> solution, but aside from that, can you explain why email.txt has to
>> sit around with email content after amavis is done processing the
>> associated message?  Does this content stay indefinitely?
>
> Don't focus on how long the file sits around.  If it's
> world-readable for 10 seconds or 10 days doesn't make that much
> difference -- it must not be world-readable.

1) The directories inside $TEMPBASE/tmp are created with amavis:amavis
rwxr-x--- permissions so they are not world readable, even when the
$TEMPBASE/tmp directory is.  Is there a problem with that?  For
example:

drwxrwxrwt 10 root   root   200 Nov 24 18:11 ./
drwxr-xr-x 23 root   root   800 Nov 24 18:03 ../
drwxr-x---  3 amavis amavis  80 Nov 24 18:00 amavis-20121124T180038-01142/
drwxr-x---  3 amavis amavis  80 Nov 24 18:10 amavis-20121124T181021-01143/

2) I agree, 10 seconds is just as bad as 10 days. In
security-sensitive environments, are there other tools people turn to
that will do this work all in-memory?