On Fri, May 19, 2023 at 10:13:09AM +0200, Christian Brauner wrote: > > I'm well aware that any file type is allowed to be in FDs 0,1,2 and > > some user space is using it that way, like old inetd: > > https://github.com/guillemj/inetutils/blob/master/src/inetd.c#L428 > > That puts the same socket into 0,1,2 before exec-ing new process. This is a *feature*. I've seen, and actually written shell scripts which have been wired into /etc/inetd.conf. amd so the fact that shell script can send stdout out to a incoming TCP connection. It should be possible to implement the finger protocol (RFC 1288) as a shell or python script, *precisely* because having inetd connect a socket to FDs 0, 1, and 2 is a good and useful thing to do. > > My point that the kernel has to assist user space instead of > > stubbornly sticking to POSIX and saying all FDs are equal. This is not a matter of adhering to Posix. It's about the fundamental Unix philosophy. Not everything needs to be implemented in a complicated C++ program.... > > To explain the motivation a bit of background: > > "folly" is a core C++ library for fb apps. Like libstdc++ and a lot more. > > Until this commit in 2021: > > https://github.com/facebook/folly/commit/cc9032a0e41a0cba9aa93240c483cfceb0ff44ea > > the user could launch a new process with flag "folly::Subprocess::CLOSE". > > It's useful for the cases when child doesn't want to inherit stdin/out/err. Yeah, sorry, that's just simple bug in the Folly library (which I guess was well named). Closing all of the file descriptors and then opening 0, 1, and 2 using /dev/null is a pretty basic. In fact, there's a convenient daemon(3) will do this for you. No muss, no fuss, no dirty dishes. > I'm sorry but I really don't think this is a good idea. We're not going > to run BPF programs in core file code. That stuff is sensitive and > complex enough as it is without having to take into account that a bpf > program can modify behavior. It's also completely unclear whether that's > safe to do as this would allow to change fd allocation across the whole > kernel. > > This idea that fd 0, 1, and 2 or any other fd deserve special treatment > by the kernel needs to die; and quickly at that. +1. Making fundamentally violent changes to core Unix design and philosophy just to accomodate incompetent user space programmers is IMHO a really bad idea. - Ted