Recent Features
| |||||||||||||
O_NOSTDO_NOSTDPosted 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.
(Log in to post comments)
O_NOSTD Posted Aug 27, 2009 2:13 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
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]
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.
|
|||||||||||||