From owner-freebsd-commit Tue Oct 17 07:11:32 1995 Return-Path: owner-commit Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA26069 for freebsd-commit-outgoing; Tue, 17 Oct 1995 07:11:32 -0700 Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA26059 for cvs-all-outgoing; Tue, 17 Oct 1995 07:11:26 -0700 Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA26049 for cvs-sys-outgoing; Tue, 17 Oct 1995 07:11:23 -0700 Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.9.13]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id HAA26044 ; Tue, 17 Oct 1995 07:10:59 -0700 Received: (from james@localhost) by miller.cs.uwm.edu (8.6.10/8.6.10) id JAA15571; Tue, 17 Oct 1995 09:10:58 -0500 Date: Tue, 17 Oct 1995 09:10:58 -0500 From: Jim Lowe Message-Id: <199510171410.JAA15571@miller.cs.uwm.edu> To: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, bde@zeta.org.au, cvs-sys@freefall.freebsd.org Subject: Re: cvs commit: src/sys/i386/isa spigot.c Sender: owner-commit@FreeBSD.org Precedence: bulk > Date: Tue, 17 Oct 1995 12:49:59 +1000 > From: Bruce Evans > To: CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, > bde@zeta.org.au, cvs-sys@freefall.freebsd.org, james@miller.cs.uwm.edu > Subject: Re: cvs commit: src/sys/i386/isa spigot.c > > >> > Modified: sys/i386/isa spigot.c > >> > Log: > >> > Don't allow i/o operations for non-root users. > >> ... > >> /dev/spigot is created with owner root.wheel and permissions 444. This > >> was previously a security hole. Now it is probably just bogus since > >> probably only root will be able to use the device. Perhaps the correct > > >At the time I wrote the spigot stuff, this seemed the only way to make > >things work. On many systems, making people run as root to capture video > >is far more insecure than granting them access to the IO page, but this > >is a matter of judgement. > > >In my case, running a video capture program as root would basically > >be the same thing as giving every user on that system root priv since > >they use the system to capture video. This doesn't sound like a > >reasonable solution either. > > Couldn't there be a server like the X server, or secure (ha!) setuid > capture programs? There could be, but you have to understand how much data video capture transfers. If there would be a suid server program, then that would require at least 2 memory copies -- one from the board to the server and one from the server to the client -- and probably one from the client to X. When you are talking about 640x480x2x30 bytes, this is a little unrealistic. I know that the ISA bus really can't run this fast, but depending on how fast one is willing to drive it, you are looking at atleast 4 meg/sec. The client must have direct access to the data without memory copies otherwise you will loose frames. That would mean the every video capture program would have to be suid - ugh! > > >The correct solution would be to map the 4 bytes of i/o space > >(read-only) into user space. With the current vm functions available, > >I didn't see any way of doing this. It seemed that one had to map all > >of i/o space or none at all. > > The current way is actually to allow use of some privileged instructions, > including i/o instructions and disabling interrupts. Interrupts would > have to be disabled to stop the standard drivers from getting control > when when you subvert them :-). What I really need is the ability to do inb/outb for setting up the card from user land and reading 4 bytes from shared i/o memory. I wouldn't have to do the inb/outb if I could put the code into the driver, but then alas, non-disclosure. > > >Is there a way of mapping one word of I/O space read-only into user space > >without allowing them access to the whole I/O page? > > Not yet. Here lies the problem... > > Bruce > -Jim