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) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org