[EMAIL PROTECTED] writes:
Well, if microseconds are added to the message's filename, then the following must now happen in order to have duplicate filenames:On Tue, Jan 14, 2003 at 12:11:05AM -0500, Sam Varshavchik wrote:I'm going to have to tell people that they'll have to use the modified deliverquota (that inserts microseconds), with Qmail if they're going to read mail with Courier-IMAP.Is there a guarantee that the same PID will not be used in the same microsecond?
* The process must finish writing the message, flushing it, and moving it to new.
* The process exits. The kernel cleans up and deallocates all the process structures.
* The kernel starts another qmail-local process, and assigns it the same pid as the previous qmail-local process. The process must be fully initialized, its runtime linker must open all ELF shared libraries; generally the CPU must enter main(), at which point, presumably, the process can obtain the current time in microseconds.
All of that has to happen within one millionth of a second.
Well, how many CPU instructions would all of this take? I'll grossly low-ball it, and say a couple of hundred (assuming that everything is cached in RAM); but its probably more like a couple of thousand, if not tens of thousands of instructions.
What is the fastest RAM available today? 800 Mhz RDRAM, I think. Meaning that, in theory, the Rambust can deliver 800 million words of RAM to the CPU per second, as an absolute theoretical maximum.
Looks like it already takes at least a microsecond for the CPU to read eight words of RAM.
In other words: not bloody likely.
CPU cache, you say? Still not going to cut it. No way, no how.
******
From: Henning Brauer <[EMAIL PROTECTED]>
Subject: Re: OpenBSD 3.2 breaks Courier, Qmail.
Date: Tue, 14 Jan 2003 12:46:31 +0100
This will end up affecting much more stuff. Plenty of code relies on the combination of pid_t+time_t being a locally-unique ID.
Then it is broken.What exactly do "random PIDs" have anything to do with anything? "Random PIDs" does not necessarily preclude pids from not being recycled within a short timeframe. In fact, I can easily think of ways to generate random pids, but prevent pids from being recycled in the same second. So one does not preclude the other.
I question you above statement. We ship with random PIDs since 6 years or so now.
I've been told that the changelog for OpenBSD 3.2 has an entry commenting that pid generation has been "simplified", or something along those lines.
Perhaps things got way too simplified.
I'm not sure I understand you. How is it a "courier implementation bug" when it can occur with only qmail-local, and mutt, being the only actors in the picture? Please be kind enough to explain your thinking, here.[2]This courier implementation bug is the first issue with that we hear of.
Or, someone just mentioned NFS. An excellent point. It is my understanding that for a CREAT, it's the NFS server that creates the new inode, and initializes it, based on the server's clock. Therefore, if the server's clock is behind, a newly created message will have a timestamp < now(), according to what both qmail-local, and qmail-pop3d sees. So, qmail-pop3d sees nothing that would prevent the message from being moved from new to cur. Meanwhile, a new qmail-local process, with the same pid is busy writing out a different message, with the same filename, and will not encounter any obstacles in moving the message file to new, when it's done.
So, I'm not sure I understand how something that can be done solely by qmail-local, and qmail-pop3d, is considered a "courier implementation bug."
Now, of course there's ntpd. Right now, two ntpd-synchronized boxes on a completely unloaded 10BaseT LAN are skewed by .02s. With the ping latency of less than 1ms, seems to me this is still big enough to drive a truck through.
So you're not really getting anything of value at all. You're merely replacing one potential race condition, with another one. So what exactly did we accomplish, here?
sorry, you don't understand the problem.
Do you?[3]
I'd appreciate a brief outline of what the inherent problem with predictable PIDs, and only predictable PIDs is, which does not exist if pid generation is not predictable. I'm mystified.predictable PIDs are a problem.
Only if it's your own processes. Well, you started them[1], so you should have every right to kill them, no?If you have the PID you can send signals and do other funky stuff.
yes, there are precautions against that too, this is multilevel security again.
Sounds more like "security through obscurity" to me.
Of course every pid is reassigned eventually. The thing is that if you see a process with pid 300, and you see a process with pid 300 a second later, then you should be fairly confident that this is the same process.ANY program that relies on PIDs not beeing reassigned within a certain timeframe is simply broken, there is no such guarantee, and never was.
[1] Ignoring the marginal case with setuid, of course, which is irrelevant to the point in hand.
[2] It is fortunate that one of my New Year's resolution for 2003 is to be more polite. Normally, as others will readily vouch for, my expected response would be a borrowed quote from Bender, the robot. But, I'm 3.8% there, and I am determined to fullfil my New Year's resolution this time.
[3] Darn. Oh well, there's always 2004.
