On Fri, Sep 21, 2018 at 11:27:59AM -0700, Andy Lutomirski wrote: > On Fri, Sep 21, 2018 at 6:39 AM Tycho Andersen <tycho@xxxxxxxx> wrote: > > > > On Thu, Sep 20, 2018 at 07:18:45PM -0700, Andy Lutomirski wrote: > > > > > > I think we just want the operation to cover all the cases. Let PUT_FD > > > take a source fd and a dest fd. If the source fd is -1, the dest is > > > closed. If the source is -1 and the dest is -1, return -EINVAL. If > > > the dest is -1, allocate an fd. If the dest is >= 0, work like > > > dup2(). (The latter could be necessary to emulate things like, say, > > > dup2 :)) > > > > ...then if we're going to allow overwriting fds, we'd need to lift out > > the logic from do_dup2 somewhere? Is this getting too complicated? :) > > > > fds are complicated :-p :D > More seriously, though, I think it's okay if we don't support > everything out of the box. getting the general semantics I suggested > is kind of nice because the resulting API is conceptually simple, even > if it encapsulates three cases. But I'd be okay with only supporting > add-an-fd-at-an-unused-position and delete-an-fd out of the box -- > more can be added if there's demand. It's the delete/replace-an-fd one that has me worried. Anyway, I'll take a look and see what I can figure out. > But I think that exposing an operation that allocates and reserves an > fd without putting anything in the slot is awkward, and it opens us up > to weird corner cases becoming visible that are currently there but > mostly hidden. For example, what happens if someone overwrites a > reserved fd with dup2()? (The answer is apparently -EBUSY -- see the > big comment in do_dup2() in fs/file.c.) But there's a more > significant nastiness: what happens if someone abuses your new > mechanism to overwrite a reserved fd that belongs to a different > thread? It looks like you'll hit the BUG_ON(fdt->fd[fd] != NULL); in > __fd_install(). So unless you actually track which unused fds you own > and enforce that the final installation installs in the right slot, > you have a problem. > > BTW, socketpair() isn't the only thing that can add two fds. > recvmsg() can, too, as can pipe() and pipe2(). Some of the DRM ioctls > may as well for all I know. But socketpair(), pipe(), and recvmsg() > can be credibly emulated by adding each fd in sequence and then > deleting them all of one fails. Sure, this could race against dup2(), > but I'm not sure we care. Yup agreed. We need to do the install when the ioctl() is called. Tycho _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
