Re: [patch 7/8] fdmap v2 - implement sys_socket2

[Al Viro]

On Sat, Jun 09, 2007 at 01:21:24PM -0700, Linus Torvalds wrote:
 
> (And dammit, that _is_ a *real*issue*. No races necessary, no NR_OPEN 
> iterations, no even *halfway* suspect code. It's perfectly fine to do
> 
> 	close(0);
> 	close(1);
> 	close(2);
> 	.. generate filenames, whatever ..
> 	if (open(..) < 0 || open(..) < 0 || open(..) < 0)
> 		die("Couldn't redirect stdin/stdout/stderr");
> 
> and there's absolutely nothing wrong with this kind of setup, even if you 
> could obviously have done it other ways too (ie by using "dup2()" instead 
> of "close + open"),
> 
> And that means that libraries currently MUST NOT open their own file 
> descriptors, exactly because they mess with the "application file 
> descriptor namespace", namely the linear POSIX-defined fd allocation 
> rules!

Unless it does so in a thread that has unshared its descriptor table.
Which is certainly safer than suggested variants and which might be
natural thing to do anyway (e.g. if we do behind-the-scene getpwent()
caching, etc., we wouldn't be hurt by doing the work asynchronously
wrt the rest of program).

It sure as hell beats the "it's probably going to be safe with expected
use patterns in programs using our library" in the safety department;
that way we *know* that nothing of our stuff will leak anywhere, just as
we know that whatever other threads might be doing, they won't screw with
our descriptors in any way.

That's independent from O_CLOEXEC, etc., and for cases where such technics
is usable we get a bonus of code working with earlier kernels just fine.

Comments?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/