Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!mtune!codas!killer!jfh
From: jfh@killer.UUCP (The Beach Bum)
Newsgroups: comp.unix.questions
Subject: Re: priv. problem
Message-ID: <1508@killer.UUCP>
Date: Wed, 9-Sep-87 16:38:10 EDT
Article-I.D.: killer.1508
Posted: Wed Sep  9 16:38:10 1987
Date-Received: Fri, 11-Sep-87 07:25:48 EDT
References: <9111@brl-adm.ARPA>
Organization: Big "D" Home for Wayward Hackers
Lines: 30
Summary: Now there's an old system call ...

In article <9111@brl-adm.ARPA>, LAGRO_4%HWALHW5.BITNET@wiscvm.wisc.EDU writes:
> 
>                                                      Wageningen 2-august-87
>     Hello,
> 
> 
>           On our Unix system (an IRONICS IV-1600/S) we use
>         some add on boards for the image processing part
>         we are working on. In order to access these boards,
>         we map them in our virtual memoryspace with the
>         PHYS-call. Here we run into our problem: In order
>         to use phys, one should be a super-user....
> 
Phys() requires you to be root so you don't map the U-page (or something
else more useful) into your address space so you can't just change your
UID to root, so in general disarming phys() is a bad idea.  Changing the
programs that access the boards to Set-UID root is about the only idea
I can come up with - that or write a device driver to read and write the
address space that is occupied by the graphics boards.

If you don't happen to have a copy of the sources to io/mem.c for the
memory device driver, they are 1). simple to write and 2). I have my own
copy I would be willing to send you.

John.
-- 
John F. Haugh II		HECI Exploration Co. Inc.
UUCP:	...!ihnp4!killer!jfh	11910 Greenville Ave, Suite 600
"Don't Have an Oil Well?"	Dallas, TX. 75243
" ... Then Buy One!"		(214) 231-0993