| |||||||||||||
Extending system callsExtending system callsPosted May 17, 2008 21:12 UTC (Sat) by jimparis (subscriber, #38647)Parent article: Extending system calls
> Currently, programs can use fcntl() to change an open file descriptor to > have the close-on-exec property, but there is always a window in time > between the creation of the descriptor and changing its behavior. Another > thread could do an exec() call in that window, leaking a potentially > sensitive file descriptor into the newly run program. Closing that window > requires an in-kernel solution. No it doesn't! Simple locking between threads would easily fix the race. See https://bugzilla.redhat.com/show_bug.cgi?id=233481 for an example. The problem with this approach appears to be poor performance.
(Log in to post comments)
Extending system calls Posted May 19, 2008 11:42 UTC (Mon) by liljencrantz (subscriber, #28458) [Link] If the fd creation is part of a library, that solution may be unacceptable.
Syscalls and locking Posted Aug 3, 2008 5:43 UTC (Sun) by smurf (subscriber, #17840) [Link] Libraries don't directly call the system; they use the glibc entry points. However, any possible locking scheme would require that execve() and open()/whatever cannot run concurrently. It's not hard to construct a program that would be hurt rather severely by that restriction.
Extending system calls Posted Oct 10, 2008 19:41 UTC (Fri) by bluefoxicy (guest, #25366) [Link]
Why not uh. fork(), then in the child (which calls exec()) call close() to drop the file handle, THEN call exec()? You know, like normal people?
|
|||||||||||||