Extending system calls [LWN.net]

Extending system calls

Posted May 17, 2008 21:12 UTC (Sat) by jimparis (guest, #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.

to post comments

Extending system calls

Posted May 19, 2008 11:42 UTC (Mon) by liljencrantz (guest, #28458) [Link] (2 responses)

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?