On Thu, May 28, 2020 at 3:59 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Thu, May 28, 2020 at 01:16:46AM +0200, Christian Brauner wrote: > > I'm also starting to think this isn't even possible or currently doable > > safely. > > The fdtable in the kernel would end up with a dangling pointer, I would > > think. Unless you backtrack all fds that still have a reference into the > > fdtable and refer to that file and close them all in the kernel which I > > don't think is possible and also sounds very dodgy. This also really > > seems like we would be breaking a major contract, namely that fds stay > > valid until userspace calls close, execve(), or exits. > > Right, I think I was just using the wrong words? I was looking at it > like a pipe, or a socket, where you still have an fd, but reads return > 0, you might get SIGPIPE, etc. The VFS clearly knows what a > "disconnected" fd is, and I had assumed there was general logic for it > to indicate "I'm not here any more". Nope. For example, pipes have manual checks based on pipe->readers and pipe->writers, and manually send SIGPIPE and stuff from inside fs/pipe.c. And pipes are not actually permanently "disconnected" - someone can e.g. open a pipe that previously had no readers in read mode, and suddenly you can write to it again. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
