Messages in this thread | | | From | Jann Horn <> | Date | Thu, 28 May 2020 06:14:28 +0200 | Subject | Re: [PATCH 1/2] seccomp: notify user trap about unused filter |
| |
On Thu, May 28, 2020 at 3:59 AM Kees Cook <keescook@chromium.org> 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.
| |