Re: fd == 0 means AT_FDCWD BPF_OBJ_GET commands

[Christian Brauner <brauner@kernel.org>]

On Thu, May 18, 2023 at 05:33:32PM +0100, Matthew Wilcox wrote:
> On Thu, May 18, 2023 at 09:25:08AM -0700, Alexei Starovoitov wrote:
> > We're still talking past each other.
> > 0 is an invalid bpf object. Not file.
> > There is a difference.
> > The kernel is breaking user space by returning non-file FDs in 0,1,2.
> > Especially as fd = 1 and 2.
> > ensure_good_fd() in libbpf is a library workaround to make sure bpf objects
> > are not the reason for user app brekage.
> > I firmly believe that making kernel return socket FDs and other special FDs with fd >=3
> > (under new sysctl, for example) will prevent user space breakage.
> 
> Wait, why are socket FDs special?  I shouldn't be able to have anything
> but chardev fds, pipes and regular files as fd 0,1,2?  I agree that having
> directory fds and blockdev fds as fd 0,1,2 are confusing and pointless,
> but I see the value in having a TCP socket as stdin/stdout/stderr.
> 
> If a fd shouldn't be used for stdio, having an ioctl to enable it
> and read/write return errors until/unless it's enabled makes sense.
> But now we have to label each fd as safe/not-safe for stdio, which we
> can as easily do by setting up our fops appropriately.  So I'm not sure
> what you're trying to accomplish here.

Yeah, I don't think we want weird ioctl()s to restrict file descriptor
ranges in any way. This all sounds pretty weird to me and I don't even
want to imagine the semantical oddness of suddenly restricting the
kernels ability to return some fds.

Honestly, most of the time sysctls such as this are the equivalent of
throwing the hands up in the air and leaving the room.