LWN: Comments on "Extending system calls"

Extending system calls

bluefoxicy — 2008-10-10T19:41:25+00:00

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?

Syscalls and locking

smurf — 2008-08-03T05:43:39+00:00

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

liljencrantz — 2008-05-19T11:42:08+00:00

If the fd creation is part of a library, that solution may be unacceptable.

Extending system calls

jimparis — 2008-05-17T21:12:01+00:00

> 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.

Stylistic gripe

nix — 2008-05-15T22:50:35+00:00

I concur. The developers don't refer to each other by last name, and are 
pretty much universally known either by first name or email address, so it 
looks really rather out of place.

Stylistic gripe

alvherre — 2008-05-15T22:25:09+00:00

This is very minor -- it was rather disapppointing to see developers being talked about by
last name.  I can only hazard that it's the standard in press, so Edge follows it, but Jon has
always seemed to prefer using first names instead and the result is better (IMVHO).

Extending system calls

i3839 — 2008-05-15T16:45:22+00:00

I'm so glad the sys_indirect approach is abandoned, it looked horrible to use (and that glibc
would provide wrapper functions is no consolidation).

Extending system calls

ncm — 2008-05-15T10:01:03+00:00

Scratch that.

Extending system calls

ncm — 2008-05-15T08:16:11+00:00

Please forgive my obtuseness (obtusity?)... why can't open() be made to do the job of all of
pipe(), socket(), etc., with all the flags and whistles one could want, leaving the
traditional entry points as special cases?