Date: Wed, 9 Apr 2008 10:06:30 -0600 From: John E Hein <jhein@timing.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org, phk@phk.freebsd.dk Subject: Re: tt_ioctl Message-ID: <18428.59782.318085.53492@gromit.timing.com> In-Reply-To: <20080409.044228.-201314267.imp@bsdimp.com> References: <18427.44466.423562.510257@gromit.timing.com> <40914.1207681578@critter.freebsd.dk> <20080409.044228.-201314267.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18428.59782.318085.53492>