Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!ncar!boulder!stan!dce
From: dce@Solbourne.COM (David Elliott)
Newsgroups: comp.unix.wizards
Subject: Re: GNU os suggestions -- system data interfaces
Message-ID: <1396@marvin.Solbourne.COM>
Date: 7 Jun 89 00:51:40 GMT
References: <1344@marvin.Solbourne.COM> <3307@uokmax.UUCP>
Reply-To: dce@Solbourne.com (David Elliott)
Organization: Solbourne Computer Inc., Longmont, Colorado
Lines: 50

In article <3307@uokmax.UUCP> rmtodd@uokmax.UUCP (Richard Michael Todd) writes:
>In article <1344@marvin.Solbourne.COM> dce@Solbourne.com (David Elliott) writes:
>>Two items that I find particularly annoying are getting kernel data
>>values and handling system files.

>  Getting kernel data values isn't too much of a problem (once you master
>nlist and friends), though as UNIX is currently implemented it's extremely
>ugly. 

Neither is programming a 6502, but luckily we don't have to program them.
The whole point of my posting was to point out an area that could use
some improvement, and GNU is all about improving Unix.

As far as it not being that much of a problem, it is, as I pointed out
a problem if the kernel you are running is not the same as the one
that you ask nlist to look at.

>  Granted, a better interface to reading kernel internal variables and
>structures would be nice, but unless the variables are documented it 
>won't do you much good.

Agreed.  If the interface were, for example, a system call made specifically
for getting this type of kernel data, you'd have to document it.
Hopefully, you could even make some of it standard (load average, for
example).

Also, why not have such an interface?  Nlist really doesn't give you
much of an advantage, and it's really gross to have to go reading
symbols out of a file, and then (sometimes) masking the address, and
then reading it.  Why not go ahead and implement a standard, simple
interface?

>Well, really such programs ought to be setgid kmem (or whatever group
>owns /dev/kmem), but still your point applies--it makes it impossible for
>Joe User to write such programs himself, and is a pain even for Joe Sysadmin.

No, they should not "ought" to be, they "must" be.  This is because
/dev/kmem is a security hole.  For years, /dev/mem was readable by
everyone, and people, like the authors of various Emacs variants, used
that.

I'll argue that /dev/kmem is more of a security hole now than ever.
I've seen two cases in the last year in which someone changed /dev/kmem
to be readable by everyone because of some free software needing to use it.
There are a lot of people who don't know it's a security hole, so
people start using it.

-- 
David Elliott		dce@Solbourne.COM
			...!{boulder,nbires,sun}!stan!dce