6 ms·

(9) every program starts with 3 streams, stdin/stdout for work and stderr for out of band errors This is false - if a process closes stdin/out/err, its childre

by enedil 6y ago

(9) every program starts with 3 streams, stdin/stdout for work and stderr for out of band errors This is false - if a process closes stdin/out/err, its children won't have these files open.

imglorp 6y ago
That's correct, which is why I said _starts_ with the streams. The child can do what it wants with them after that.
- DSMan195276 6y ago
  His point was that if you close stdin/stdout/stderr and then fork a child, the new child will not have all of those streams when it starts - the three streams are a convention, not something enforced by the kernel when creating a new process. That said, it's still a bit of a pedantic point, you can expect to always have those three fds in the same way you can expect `argv[0]` to represent the name of your executable (Which also isn't enforced by the kernel).
  - JdeBP 6y ago
    Actually, it's not a pedantic point. It's a security flaw waiting to happen (as it actually has) if one assumes that one always has three open file descriptors. The privileged program opens a sensitive data file for writing, it gets assigned (say) file descriptor 2, because someone in a parent process took some advice to "close your standard I/O because you are a dæmon" to heart, other completely unrelated library code somewhere else blithely logs network-supplied input to standard error without sanitizing it, and (lo!) there's a remotely accessible file overwrite exploit of the sensitive data file. Ironically, the correct thing to do as a dæmon is to not close standard I/O, but to leave setting it up to the service management subsystem, and use it as-is. That way, when the service management subsystem connects standard output and error to a pipe and arranges to log everything coming out the other end, daemontools-style, the idea actually works. (-:

6 ms·

(9) every program starts with 3 streams, stdin/stdout for work and stderr for out of band errors This is false - if a process closes stdin/out/err, its childre

by enedil 6y ago

(9) every program starts with 3 streams, stdin/stdout for work and stderr for out of band errors This is false - if a process closes stdin/out/err, its children won't have these files open.

imglorp 6y ago
That's correct, which is why I said _starts_ with the streams. The child can do what it wants with them after that.
- DSMan195276 6y ago
  His point was that if you close stdin/stdout/stderr and then fork a child, the new child will not have all of those streams when it starts - the three streams are a convention, not something enforced by the kernel when creating a new process. That said, it's still a bit of a pedantic point, you can expect to always have those three fds in the same way you can expect `argv[0]` to represent the name of your executable (Which also isn't enforced by the kernel).
  - JdeBP 6y ago
    Actually, it's not a pedantic point. It's a security flaw waiting to happen (as it actually has) if one assumes that one always has three open file descriptors. The privileged program opens a sensitive data file for writing, it gets assigned (say) file descriptor 2, because someone in a parent process took some advice to "close your standard I/O because you are a dæmon" to heart, other completely unrelated library code somewhere else blithely logs network-supplied input to standard error without sanitizing it, and (lo!) there's a remotely accessible file overwrite exploit of the sensitive data file. Ironically, the correct thing to do as a dæmon is to not close standard I/O, but to leave setting it up to the service management subsystem, and use it as-is. That way, when the service management subsystem connects standard output and error to a pipe and arranges to log everything coming out the other end, daemontools-style, the idea actually works. (-: