Access to kmem - System namelist - 'ps' etc

[gijs]

In <161 at dido.UUCP> john at dido.UUCP (John Collins) writes:
>Why do so many commands such as 'ps', 'ipcs' and what have you have to use
>the /unix namelist to find out kernel addresses?
>I'd like to propose subdivisions of /dev/kmem, thus
>	/dev/kmem/proc		for the process table
>	/dev/kmem/inode		for the inode table
>and so forth. Implementation would be trivial.
>Think of the advantages:
>1.	"Anyone" could write their own "ps" without being superuser with
>	X-ray vision on /dev/*mem etc.

And what about the X-ray vision on /dev/swap?

>2.	You could control access to the various bits as you wished - no
>	worrying about people monitoring clists for passwords etc.

The best thing to do is *not* to give any access to system tables.
Accessible tables will soon be used by many application programs which
prevents format changes of such tables. 

And even if you restrict access to the super user it would be a bad
idea. Adding some feature to a ps-like program should never mean
adding another "view" to a kernel driver. 

There are also practical problems:
  - how do you interpret pointers to things?
  - what to do if you need many tables (=files) open at the
    same time on small machines?

>3.	Ps would run a lot faster not having to pick its way through the
>	symbol table of /unix.

I suspect that ps spends most of its time reading swap files.

	Gijs Mos,
	Free University
	Dept of Biology
	Amsterdam	{seismo,decvax,philabs}!mcvax!sara70!gijs