Your message dated Tue, 27 Aug 2013 22:02:56 -0600
with message-id <20130828040256.ga11...@mix.mmjgroup.com>
and subject line Re: Bug#718276: Postmap uses a known temp file for its work
has caused the Debian Bug report #718276,
regarding Postmap uses a known temp file for its work
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
718276: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718276
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: postfix
Version: 2.9.6-2
Severity: critical
Hi,
I have just discovered that postmap acts in a very bad way when it
is trying to generate its .db files. Let's say that we want to do:
postmap /some/path/postfix_virtual_uid_mapping
(real life example for me)
Then postmap will try to generate a file called:
/some/path/__db.postfix_virtual_uid_mapping.db
Once it's done, it will rename that file as expected to:
/some/path/postfix_virtual_uid_mapping.db
I guess postmap is doing this way to run atomic operation. That's a
good idea, however, it should *never* use a known file name and
handle failures the way it does.
If for some reasons that file already exists, then postmap will try
again and again (for an unreasonable amount of time) to open that
temporary file, until it will give up. That is really bad because:
1/ Someone can simply create that file to confuse postmap and DOS it.
2/ If for some reason your server fails at the time of the generation
of the temporary .db file, then you might not understand what happens
and break the next attempt to run postmap.
One of the failure modes includes a full HDD with no space remaining.
In such a case, then postmap will succeed in creating the temp file,
but it will not succeed in filling it with data. And in such a case,
it will just give-up, leaving the file on the HDD, which breaks the
next retry the administrator may attempt. Postmap should at least
give a clue of what's going on, but it doesn't (see point 3), it just
appears to be stuck doing nothing, and control-C or control-Z doesn't
work at all.
3/ There's no clear error message telling what's happening. I had to
strace it to understand what the fuck it was doing.
4/ This is simply *not* the way to handle temp files. Postmap should
be using a random file name, like for example using mktemp.
Alltogether, this is to my view, a very dangerous security problem
that should be urgently fixed.
Cheers,
Thomas Goirand (zigo)
--- End Message ---
--- Begin Message ---
severity 718276 wishlist
tag 718276 wontfix
--
On Tue, Jul 30, 2013 at 01:10:48AM +0800, Thomas Goirand wrote:
> There's no way to know where "/some/path" is, this is decided by the
> administrator of the mail server (you can use any path you configure in
> /etc/postfix/main.cf).
postmap deletes the file if it exists, and then opens the file
O_EXCL|O_WRITE, which will fail if it exists. The only exposure here is
that the user may find that the admin wins the conflict over the
existance of the file.
> However, as there are so many ways to use postfix, I am convinced that
> there are many cases where the temporary used with postmap can be
> written by a malicious user (or it just stays, as I explained, if the
> HDD is full...). So that's grave enough to be considered.
I am even more convinced that there is not a bug here that lets a
malicious user write postfix files that he shouldn't. Please demonstrate
that there is actually a bug here.
lamont
--- End Message ---
