January 2008 - Darwin-dev - lists.apple.com

Re: execv bug???
by seebs＠seebs.net 27 Jan '08

27 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com In message <479C488E.7020605(a)yahoo.com>, Steve writes: >Could this actually be a combination of execv AND the use of vfork? Yes. >So, is this a known issue perhaps? Sounds likely! >Indeed, change vfork to fork causes the problem to go away. execv then >works fine. Ah-hah! Using vfork does explain everything -- and makes sense of the decision to use _exit(). -s _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: execv bug???
by seebs＠seebs.net 27 Jan '08

27 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com In message <8EDA245D-A958-4376-A379-4331AF6FBAB3(a)comhem.se>, Tommy Nordgren wri tes: >If you want a call that uses the PATH environment variable you should >use execvp instead of execv He's not trying to use PATH -- he's trying to use a non-absolute path. >Actually, I'ts preferable to use a call that Don't use the PATH >environment variable, and specify the absolute path >of the executable instead. Agreed, especially because execvp doesn't search for binaries if the path argument contains even one slash, even if it's not at the front of the path. -s _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: execv bug???
by seebs＠seebs.net 27 Jan '08

27 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com In message <479C43B1.3000400(a)yahoo.com>, Steve writes: >This was not to be a debate on what is the best MTA. I respectfully >disagree on all counts. Postfix will not do half of the things we use >qmail for. But no matter, not the point. I've used and managed both. The >question is about execv. At least one count is the claim that qmail is unmaintained. I would be shocked if this were not still true. >I disagree, your test is not the same. What distinction do you think matters? I have chdir'd to a directory and called execv with a non-absolute path. >Recall, qmail is the second most deployed MTA ,and, the code works on >all platforms, including Tiger as is. I am aware of a number of patches that are being distributed to make the code even compile on some platforms. >The code appears correct. Like much djb code, it appears correct, but it is gratuitously clever. >The >extra code shows it to be in the right directory, as it does when >rec-compiled on our Tiger servers. So, my conclusion is different. >Anyone else? Can we stick to the topic? Be less prickly. I performed a trivial test of the exact scenario described -- chdir to a directory, call execv with a non-absolute path. It worked. This suggests that execv is certainly capable of working with non-absolute paths. I can't prove that it will work with every possible non-absolute path, from every possible directory, but it seems clear that it is working with at least one non-absolute path, from at least one directory. -s _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: execv bug???
by seebs＠seebs.net 27 Jan '08

27 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com In message <ECF90C22-4D4E-46C0-AD7D-93A2F4A1681F(a)pahtak.org>, Steve Checkoway w rites: >On Jan 27, 2008, at 12:12 AM, Peter Seebach wrote: >> In message <479C20CF.1080900(a)yahoo.com>, Steve writes: >>> if (chdir(auto_qmail) == -1) _exit(61); >>> execv(*binqqargs,binqqargs); >>> _exit(120); >> Calling _exit from user code is nearly always a mistake. >This is not true at all. In general it is, but.. >If you call fork(2) and a subsequent exec* >fails, then you must call _exit(2). Well, not necessarily. You may need to, if... >exit(3) calls functions registered >with atexit, flushes open output streams, closes open streams, and >unlinks files created with tmpfile(3).Calling exit(3) will cause the >open output streams to flush twice. I somehow doubt that djb's code uses tmpfile(). It is possible that it leaves output streams unflushed, but I'd be surprised. But yes -- this is presumably the path leading to an exec, so failures should avoid doing all that cleanup. If there is any, which I would rather doubt. >So the program you want to execute is /var/qmail/bin/qmail-queue? >Seems like a strange place for it. It is a strange place, but that's how qmail works -- it puts everything in /var/qmail. >> static char *ev[] = { 0, 0 }; >> >> int >> main(void) { >> ev[0] = "bin/ls"; >> chdir("/"); >> execv(*ev, ev); >> return 23; >> } >> >You're assigning a const char * to a char *. No I'm not. >I'm not sure why gcc >doesn't warn about this, but I suspect that it should. In fact, if you >assign "bin/ls" to a const char * first, then it does warn, "warning: >assignment discards qualifiers from pointer target type." Well, yes. Because then there'd be a const char * involved. String literals are not const-qualified, even though their contents may not be modified. -s _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: execv bug???
by Tommy Nordgren 27 Jan '08

27 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 27 jan 2008, at 07.12, Steve wrote: if (chdir(auto_qmail) == -1) _exit(61); execv(*binqqargs,binqqargs); _exit(120); binqqargs is defined as: static char *binqqargs[2] = { 0, 0 } ; Later it is set as: binqqargs[0] = "bin/qmail-queue"; auto_qmail contains the path /var/qmail It works perfectly on Tiger, freeBSD, you name it. If I change binqqargs to /var/qmail/bin/qmail-queue, all works fine. Steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/tommy.nordgren%40comhem.se Tommy Nordgren tommy.nordgren(a)comhem.se _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… If you want a call that uses the PATH environment variable you should use execvp instead of execv Actually, I'ts preferable to use a call that Don't use the PATH environment variable, and specify the absolute path of the executable instead. Have a well known program, qmail, compiled on Leopard. We've used it for 3 years or so on Mac Tiger et al. qmail runs on most any platform out there. In the code, are the following lines: So, the chdir on all other platforms goes to /var/qmail, and, the execv executes from there bin/qmail-queue. The execv (added more code) returns an error 2, or, file not found on Leopard. Could it be a bug in execv on Leoprd when when not using a absolute filename? If so, what is the mechanism to report and hopefully some day get it fixed? This email sent to tommy.nordgren(a)comhem.se ----------------------------------- See the amazing new SF reel: Invasion of the man eating cucumbers from outer space. On congratulations for a fantastic parody, the producer replies : "What parody?" This email sent to site_archiver(a)lists.apple.com

1 0

Re: execv bug???
by Steve Checkoway 27 Jan '08

27 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jan 27, 2008, at 12:12 AM, Peter Seebach wrote: if (chdir(auto_qmail) == -1) _exit(61); execv(*binqqargs,binqqargs); _exit(120); No, because as a simple test program shows, that works: static char *ev[] = { 0, 0 }; int main(void) { ev[0] = "bin/ls"; chdir("/"); execv(*ev, ev); return 23; } -- Steve Checkoway "Anyone who says that the solution is to educate the users hasn't ever met an actual user." -- Bruce Schneier _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com In message <479C20CF.1080900(a)yahoo.com>, Steve writes: Calling _exit from user code is nearly always a mistake. This is not true at all. If you call fork(2) and a subsequent exec* fails, then you must call _exit(2). exit(3) calls functions registered with atexit, flushes open output streams, closes open streams, and unlinks files created with tmpfile(3).Calling exit(3) will cause the open output streams to flush twice. So, the chdir on all other platforms goes to /var/qmail, and, the execv executes from there bin/qmail-queue. So the program you want to execute is /var/qmail/bin/qmail-queue? Seems like a strange place for it. You're assigning a const char * to a char *. I'm not sure why gcc doesn't warn about this, but I suspect that it should. In fact, if you assign "bin/ls" to a const char * first, then it does warn, "warning: assignment discards qualifiers from pointer target type." That said, execv(3) works for me without an absolute path as well. smime.p7s

1 0

Re: execv bug???
by Steve 27 Jan '08

27 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=prwCCuxhr1pLaXCV9MHeBcdi903QGbpQ1lUbX2M9vScNIgjc6on/RnffOZF2DQIPs4w7xlSoWfMlFSLvdVkOO+n3k1Acg1vS3shzoi6VzWjzN5s0j5+h8nKsmQXu6g7Uh4v4KcEBd1p6Mq4sKiXOcZekDIqH4b+ETYhwUnvBA6w= ; User-agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Could this actually be a combination of execv AND the use of vfork? I see other reports of this out there, such as this comment: So, is this a known issue perhaps? Steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… "on Darwin x86_64, disable use of vfork as it causes execve to fail intermittently." Indeed, change vfork to fork causes the problem to go away. execv then works fine. This email sent to site_archiver(a)lists.apple.com

1 0

Re: execv bug???
by Steve 27 Jan '08

27 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qPNVGm4+lwbIe24Zn1UJ3wMwu4gF5SMbVZyHq/jx7QRx83zju/+Sk0UpiMJy5tOgKuKwUQnqdwOQYZ14zToHHzW5vurZBCBzBVP1HIgB1clWiJepeMwNmDEQA2GviX0f6eOu7Sl23e1DWlNJeVPTz6agHwcgTvvAWxOSkhJ9avY= ; User-agent: Thunderbird 2.0.0.9 (Macintosh/20071031) No, because as a simple test program shows, that works: static char *ev[] = { 0, 0 }; int main(void) { ev[0] = "bin/ls"; chdir("/"); execv(*ev, ev); return 23; } This will run ls and return 0, suggesting that execv can handle non-absolute path names. I disagree, your test is not the same. Steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Peter Seebach wrote: I would suggest switching to postfix. qmail is unmaintained, and while no one would accuse djb's code of being a forest of security holes, it's not exactly written with an aggressive eye to language standards or portability. This was not to be a debate on what is the best MTA. I respectfully disagree on all counts. Postfix will not do half of the things we use qmail for. But no matter, not the point. I've used and managed both. The question is about execv. The execv (added more code) returns an error 2, or, file not found on Leopard. That's odd. I'd probably replace it with "/bin/pwd" and see what it says. :) It says the correct directory. Which is to be expected. Could it be a bug in execv on Leoprd when when not using a absolute filename? Conclusion: Something else has gone wrong. Recall, qmail is the second most deployed MTA ,and, the code works on all platforms, including Tiger as is. The code appears correct. The extra code shows it to be in the right directory, as it does when rec-compiled on our Tiger servers. So, my conclusion is different. Anyone else? Can we stick to the topic? This email sent to site_archiver(a)lists.apple.com

1 0

Re: execv bug???
by seebs＠seebs.net 27 Jan '08

27 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com In message <479C20CF.1080900(a)yahoo.com>, Steve writes: >Have a well known program, qmail, compiled on Leopard. We've used it for >3 years or so on Mac Tiger et al. I would suggest switching to postfix. qmail is unmaintained, and while no one would accuse djb's code of being a forest of security holes, it's not exactly written with an aggressive eye to language standards or portability. >qmail runs on most any platform out there. In the code, are the >following lines: > if (chdir(auto_qmail) == -1) _exit(61); > execv(*binqqargs,binqqargs); > _exit(120); Calling _exit from user code is nearly always a mistake. >So, the chdir on all other platforms goes to /var/qmail, and, the execv >executes from there bin/qmail-queue. Makes sense. >The execv (added more code) returns an error 2, or, file not found on >Leopard. That's odd. I'd probably replace it with "/bin/pwd" and see what it says. :) >Could it be a bug in execv on Leoprd when when not using a absolute >filename? No, because as a simple test program shows, that works: static char *ev[] = { 0, 0 }; int main(void) { ev[0] = "bin/ls"; chdir("/"); execv(*ev, ev); return 23; } This will run ls and return 0, suggesting that execv can handle non-absolute path names. Conclusion: Something else has gone wrong. To debug this, you'd presumably need to add all sorts of extra debugging code, possibly instrumenting libc (as I think execv may be implemented in terms of one of the other exec syscalls), etcetera. I wouldn't bother; postfix is better anyway. -s _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

execv bug???
by Steve 27 Jan '08

27 Jan '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=wOItKoVLwz+YY7HvR1CO7LaCWx2O34+cPpU6pUwsk+1w2XhZ9DEvDqz0L/wvuehOvmOk87OfPyd+arnL5tIT/2MTNbQ7Oh5QvkMrH8Bn3/pz9tmGMNsmEAhMxPDQ9dlG7E+EuW2dDNPZl8Q90SSA6dEtKMDvRTO7f8rH9pAUzVI= ; User-agent: Thunderbird 2.0.0.9 (Macintosh/20071031) if (chdir(auto_qmail) == -1) _exit(61); execv(*binqqargs,binqqargs); _exit(120); binqqargs is defined as: static char *binqqargs[2] = { 0, 0 } ; Later it is set as: binqqargs[0] = "bin/qmail-queue"; auto_qmail contains the path /var/qmail It works perfectly on Tiger, freeBSD, you name it. If I change binqqargs to /var/qmail/bin/qmail-queue, all works fine. Steve _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Have a well known program, qmail, compiled on Leopard. We've used it for 3 years or so on Mac Tiger et al. qmail runs on most any platform out there. In the code, are the following lines: So, the chdir on all other platforms goes to /var/qmail, and, the execv executes from there bin/qmail-queue. The execv (added more code) returns an error 2, or, file not found on Leopard. Could it be a bug in execv on Leoprd when when not using a absolute filename? If so, what is the mechanism to report and hopefully some day get it fixed? This email sent to site_archiver(a)lists.apple.com

1 0