From owner-freebsd-commit  Mon Oct 16 19:54:21 1995
Return-Path: owner-commit
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id TAA05534
          for freebsd-commit-outgoing; Mon, 16 Oct 1995 19:54:21 -0700
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id TAA05468
          for cvs-all-outgoing; Mon, 16 Oct 1995 19:52:52 -0700
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id TAA05458
          for cvs-sys-outgoing; Mon, 16 Oct 1995 19:52:49 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA05452
          ; Mon, 16 Oct 1995 19:52:30 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id MAA20755; Tue, 17 Oct 1995 12:49:59 +1000
Date: Tue, 17 Oct 1995 12:49:59 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510170249.MAA20755@godzilla.zeta.org.au>
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
Sender: owner-commit@FreeBSD.org
Precedence: bulk

>> >  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?

>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 :-).

>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.

Bruce