Date: Thu, 23 Feb 1995 06:56:25 -0800 From: Paul Traina <pst@shockwave.com> To: "Ugen J.S.Antsilevich" <ugen@netvision.net.il> Cc: current@FreeBSD.org Subject: Re: snp(4)/watch(8) code review comments Message-ID: <199502231456.GAA16315@precipice.Shockwave.COM> In-Reply-To: Your message of "Thu, 23 Feb 1995 12:17:22 %2B0700." <Chameleon.950223122543.ugen@ugen.NetManage.co.il>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "Ugen J.S.Antsilevich" <ugen@NetVision.net.il> Subject: RE: snp(4)/watch(8) code review comments >I did a preliminary run through the snp device code that you added and had >some comments to make. No insult intended, but I see room for improvement >here: > >(a) we should document that this device is a BIG security hole and people > should only compile it into their kernels if they're willing to > take that risk Hmm..actually this is security help:) At least for me...:) If one already has root access to open /dev/snp (which is openable ONLY by root),he already foun security breach and doesn't need another one..:) Well, I used to think that way, but over the past 12 months, I've learned just how nasty session sniffing can be, as I now have to worry about the machines of all of the users connected to my machine. It makes it that much easier for the bad guys to waltz from machine to machine. >(b) It seems to me that having to specify the type of tty that you're > looking at is brain-dead. I see that you've got knowledge of the > tty structures for the ptys, sios, and vtys. All of this information > is already in the cdevsw table and you should be accessing it via > those vectors, not through your own back-door interface. Hmm..actually i agree with you and i also thought to do it that way... The only thing here is the fact you'll need to change watch utility to get an types of tty... ( i personally prefer to write "pty8" instead of "ttyp8" but this is really simple task..)..So you'r right and this should be done pro Good, I'm glad we're in alignment there. I started whacking at a private copy of it last night and it's actually pretty far along, however there's one change I want to make to the system to do this cleanly. I want to add a new field to cdevsw[] that is a vector to a function in the driver that will return a pointer to the right struct tty element given a major/minor number. This sort of decision needs to be done locally to the driver to account for things like major/minor number masking (e.g. cua0 vs ttyd1 in the sio driver). Does anyone have an objection to my adding this new field? It will simply be NULL for any device not supporting that vector and all invocations of it test for non-NULL first before calling. >Would you consider making these changes before 2.1 ships? If not, would >you mind if I changed the interface and watch and fixed it? Hmm...hmm..actually i thought to do it myself but if you want-you can do it,i mind..Wait,say, till 26-27,if i don't do it-you do it...If you impatient thou you can do it now-just notify me...:) Actually, I'm just doing it on general principles, I never actually intend to use the snp drivers in real life, I was just digging through things and didn't like the current interface so I started hacking on it. If you want, I can feed you what I've done so far, or just finish it up this weekend. Paul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502231456.GAA16315>