User: Password:
Subscribe / Log in / New account

Extending system calls

Extending system calls

Posted 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 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 (guest, #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?

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds