O_NOSTD

Posted Aug 27, 2009 1:50 UTC (Thu) by corbet (editor, #1)
In reply to: O_NOSTD by pr1268
Parent article: In brief

That's the point: those file descriptors are defined in the standards. That's why application programmers expect them to be set up correctly. But nothing forces that to happen, and other standard-ordained behavior says that new files are always assigned the lowest available file descriptor.

to post comments

O_NOSTD

Posted Aug 27, 2009 2:13 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] (2 responses)

SUS also says that exec() of a setuid executable may assign file descriptors 0, 1, and 2 to unspecified files if they are not already assigned.

O_NOSTD is utterly pointless as it would need to be added all over the place, including libraries outside the application programmer's control.

O_NOSTD

Posted Aug 27, 2009 9:47 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

I think if the kernel developers don't have the guts to just turn on O_NOSTD
for all open() calls by default, then maybe the C library will. (With an
O_ALLOW_STD flag for those cases like the shell where you really do want to
fiddle with the standard file descriptors.)

O_NOSTD

Posted Aug 28, 2009 0:53 UTC (Fri) by willy (subscriber, #9762) [Link]

This was already fixed years ago after Chuck Lever came up with the problem originally. Try running a setuid program with a standard file descriptor closed. You'll find that libcrt0 opens them again.