The other thing to note is that while the *convention* may be that 0, 1, and 2 are for stdin, stdout, and stderr, this is a *userspae* convention. After all, system daemons like getty, gnome-terminal, et. al, need to be able to open file descriptors for stdin, stdout, and stderr, and it would be.....highly undesirable for the kernel to have to special case those processes from being able to open those file descriptors. So in the eyes of Kernel to Userspace API's we should not specially privilege the meaning of file descriptors 0, 1, and 2. Besides, we have a perfectly good way of expressing "not a FD" and that is negative values! File descriptors, after all, are signed integers. Finally, by having some kernel subsystem have a different meaning for fd 0 means that there are potential security vulernabilities. It may be the case that userspace *SHOULD* not use fd 0 for anythingn other than stdin, and that should be something which should be handed to it by its parent process. However, consider what might happen if a malicious program where to exec a process, perhaps a setuid process, with fd 0 closed. Now the first file opened by that program will be assigned fd 0, and if that gets passed to BPF, something surprising and wonderous --- but hopefully not something that can be leveraged to be a high severity security vulnerability --- may very well happen. So if there is anyway to that we can change the BPF API's to change to use negative values for special case meanings, we should do it. Certainly for any new API's, and even for old API's, Linus has always said that there are some special case times when we can break the userspace ABI --- and security vulnerabilites are certainly one of them. Best regards, - Ted
