Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC830713); site vu44.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!whuxlm!akgua!sdcsvax!sdcrdcf!hplabs!hao!seismo!mcvax!vu44!jack
From: jack@vu44.UUCP (Jack Jansen)
Newsgroups: net.unix-wizards
Subject: Re: Acessing kmem, how about a driver? (really UN*X security)
Message-ID: <536@vu44.UUCP>
Date: Thu, 27-Dec-84 05:39:56 EST
Article-I.D.: vu44.536
Posted: Thu Dec 27 05:39:56 1984
Date-Received: Sat, 29-Dec-84 05:31:30 EST
References: <813@druky.UUCP> <295@rlgvax.UUCP> <2242@garfield.UUCP>
Organization: The Retarded Programmers Home, VU, Amsterdam
Lines: 29

I was thinking of making a modified kmem driver, especially for
things like 'ps', etc. It would incorporate a structure like

struct pmdevs {
	caddr_t pm_start;
	caddr_t pm_esize;
	caddr_t pm_last;
} pmdevs[] = {
	&u, sizeof(u), u+sizeof(u),	/* U area */
	&procs, sizeof(*procs), &procs[NPROCS], /* process table */
	....
	}

Every minor device would be associated with one of the entries in the
array, and would adress memory from pm_start to pm_last.
In this way, you could protect every table by it's own minor h
device, making superuser permission for things like 'ps' unnecesary.

The 'pm_esize' gives the size of a single entry. It can be collected
via a ioctl call, so the user program could for instance check whethet
the size of a certain structure hasn't changed since it was
compiled.

Does this seem like a feasible idea? If it is, has anyone implemented
it already, or something similar?
-- 
	Jack Jansen, {seismo|philabs|decvax}!mcvax!vu44!jack
	or				       ...!vu44!htsa!jack
If *this* is my opinion, I wasn't sober at the time.