[PATCH 0/4] Load ioctl handlers from server

[Carl Fredrik Hammar]

Hi,

here comes a patch series that implements the brunt of the glibc side of
loading ioctl handlers from servers.  The only major missing part is the
reverse authentication to establishes trust in the server.  Though this is
pretty orthogonal and requires more changes to the Hurd than glibc.  So I
thought this was a nice point to send in what I have so far for review.

The first patch fixes a bug in one of the ioctl handlers.  The handler
extracts the descriptors underlying port twice, while in the mean time
the port could change.  The second patch is a very simple clean-up.

The fun starts in patch three, where we load an ioctl handler from the
server each time ioctl is called.  Of note here is how I load the port
specified module using the dlopen which operate on a path... which
isn't very pretty.  The only way to make it pretty involves making a
Hurd specific dlopen, which I'm not sure we'd want.

The last patch saves the ioctl handler between ioctl calls.  This required
that the descriptor is locked until a handler is found that accepts
the ioctl, which means that the lock must be held inside the handlers
and unlocked by the right handler before doing any RPCs.  This is quite
complicated and messy.

This can be made much cleaner for handlers which simply send an RPC,
which is the intended use-case for server provided ioctls.  As long
as ioctl() can tell that a such a handler will handle an ioctl before
calling it, it could simply extract the descriptors ports, unlock it,
and call a simple handler of type error_t (*) (io_t port, io_t ctty).

There is one ioctl handler that operate on the descriptor itself though,
and I suspect two handlers that operate on the entire descriptor table
that should hold the lock to the descriptor for the duration.  But I
don't see a use-case for overriding these ioctls, so perhaps they should
just be handled separately.  What do you think?

Also of note in the patch is that the descriptor is unlocked while the
ioctl handler is loaded.  Actually only  because _hurd_intern_fd also
attempts to lock it, but more importantly because holding a lock during
an RPC is a bad idea.  Note that if the underlying port changes during
the unlock, the load is retried.

I'm not sure if it's worth while sending in the accompanying Hurd patches
which just adds an interface and a test case.  I think I'll wait with
that until I have the reverse authentication going which is my next step.

Regards,
  Fredrik

Carl Fredrik Hammar (4):
  Don't resolve FD's port and ctty twice for TIOCSCTTY
  Cast with ioctl_handler_t instead of its definition
  Reload fd ioctl handler on each call to ioctl
  Save handlers between calls to ioctl

 hurd/Makefile             |    7 +-
 hurd/dtable.c             |    8 ++-
 hurd/fd-close.c           |   13 +++-
 hurd/fd-ioctl-call.c      |  204 +++++++++++++++++++++++++++++++++++++++++++++
 hurd/fd-ioctl-cleanup.c   |   31 +++++++
 hurd/hurd/fd.h            |   45 ++++++++++-
 hurd/hurd/ioctl.h         |   12 ++-
 hurd/hurdioctl.c          |  166 +++++++++++++++++++++++++++---------
 hurd/new-fd.c             |    7 ++-
 hurd/port2fd.c            |   11 ++-
 sysdeps/mach/hurd/ioctl.c |   51 ++++++++++-
 11 files changed, 497 insertions(+), 58 deletions(-)
 create mode 100644 hurd/fd-ioctl-call.c
 create mode 100644 hurd/fd-ioctl-cleanup.c