Re: posix_spawn[p] less secure on Hurd than on Linux

Hello, Bruno Haible, le jeu. 24 déc. 2020 02:54:28 +0100, a ecrit: > this misfeature was withdrawn from glibc in > > and > . > > But the test p

Re: posix_spawn[p] less secure on Hurd than on Linux

Thanks for reporting Bruno! Pointing out issues with GNU/Hurd's glibc is super helpful! -- Joshua Branson Sent from Emacs and Gnus https://gnucode.me https://video.hardlimit.com/accounts/joshua_branson/video-channels https://propernaming.org "You can have whatever you want, as long as

posix_spawn[p] less secure on Hurd than on Linux

Hi, In glibc versions < 2.15, posix_spawn and posix_spawnp did execute a script (with execution bits set) even if it did not start with a '#!' marker. Then, /bin/sh was used as an interpreter. You can imagine how easily a text file, which happens to set execution bits set because

Re: posix_spawn in gcc

On Thu, Jun 13, 2002 at 05:59:14PM -0700, James Morrison wrote: >I recently went though some discussions about gcc using posix_spawn instead > of fork/exec. I think linux should be the special case instead of GNU being > the special case. so the ifdef would be > #

Re: posix_spawn in gcc

I think there was also some sentiment that people would not object to using posix_spawnp on Linux if the generic glibc implementation were made more efficient. The only efficiency that can really be gotten in a generic POSIX.1 implementation over what glibc has now is to avoid using malloc when t

posix_spawn in gcc

Hi, I recently went though some discussions about gcc using posix_spawn instead of fork/exec. I think linux should be the special case instead of GNU being the special case. so the ifdef would be # if !defined(HAVE_POSIX_SPAWNP) || defined(__linux__) Is there a better way to handle this

[roland@frob.com: use posix_spawn in pexecute]

Here's a patch to the current gcc sources to make it use posix_spawn. If you're building your own gcc on hurd, please try this. With that built, you could try building your own libc (2.3) and then you'd be testing the new Hurdish implementation when you use the new gcc. --

Re: posix_spawn

Roland McGrath <[EMAIL PROTECTED]> writes: > A really useful test would be someone were to port a useful program like > make to use posix_spawn in place of fork + exec and do some real-world > tests (compiles and such) using that. The three programs that I would most strongly s

Re: posix_spawn

of. A simple thing you can do is extend utils/shd.c to give you a way to use posix_spawn and try a bunch of random tests via that. A really useful test would be someone were to port a useful program like make to use posix_spawn in place of fork + exec

Re: posix_spawn

> Now that people are able to build libc, I'd like somebody to try out > my posix_spawn implementation. Plop this into sysdeps/mach/hurd/spawni.c, > rebuild libc, and then try the `tst-spawn' test in posix. Then you get to > debug it for me. As described in the com

Re: posix_spawn

> Just out of curiosity, is posix_spawn a standard interface? And > is it reasonable for programs to expect to have it available > on a system that say, doesn't use glibc? It's specified by some newfangled draft standard, as a new POSIX option. It is not a GNU invention.

Re: posix_spawn

On Sat, Jun 16, 2001 at 05:53:52AM -0400, Roland McGrath wrote: > It has been noted that the slowness of fork on the Hurd may be a > substantial factor in uses like large builds. One way to avoid this > problem is to avoid fork. In glibc we have providing posix_spawn > and relat

posix_spawn

It has been noted that the slowness of fork on the Hurd may be a substantial factor in uses like large builds. One way to avoid this problem is to avoid fork. In glibc we have providing posix_spawn and related functions; most common cases where a program uses fork and exec directly can be