tt_ioctl

[John E Hein]

M. Warner Losh wrote at 04:42 -0600 on Apr  9, 2008:
 > I think I may have originally added the code that John proposed to the
 > tsc tree (or maybe just my private tree when I was investigating the
 > problem for others at TSC).

It wasn't checked in the local tree - I guess we came up with it
independently (assume you're talking about hooking up t_ioctl?).


 > I think it is the right way to go, and that the ioctl vs security
 > argument is a bit specious.

Well, I could go either way on this issue - 'specious' might be a bit
too strong.  I could see issues with pass-through device-specific
ioctls on tty devs - especially due to the fact that it's a tty device
is somewhat obscured in the case of ucom children.

On the other hand, tty-based devices are generally protected by other
mechanisms (notably unix file permissions).  And driver writers should
be aware of security implications of ioctls they expose.  That
requires a bit of thought and more comprehensive system knowledge,
however, and maybe it's better to just keep it simple and only allow
tty ioctls on tty devices.

That said... if we do decide to _not_ hook up t_ioctl, then we should
just remove it entirely since it's misleading that it's there but not
hooked up.

The only thing that remains then (if we remove it) would be what to do
with the drivers that have been broken for 3+ years since the ioctl
pass-through was removed (digi and the usb driver or two I mentioned
in the previous email).  Does anyone need to use the unhooked ioctls?
How do we find out if they are or are not needed any longer (other
than just leaving them unhooked and wait for PRs to appear or not)?  I
guess that just a more public call might be in order (-stable,
-current?).

Thanks for the responses so far, by the way.