Hi,

My $.02 worth...

The arguments presented here would not be the ones that
would compell me to not use /kern.  I regard /kern as a
neat thing that shell programs can use to get at some
kernel stuff.  

Presuming that there is a comparison between syscall(2)
and /kern, I would presume the applicationt to be some
sort of 'C' program.  

I have lived in the Linux world for about 4 years and 
at first I thought /proc was the greatest thing--until
I had to start writing parsers to make sense of the data
in a way useful to the programs that I was writting at
the time.  Then the format changed of some of the things
(IIRC -- /proc/net/route) and I had to redo most of it.

Granted BSD is more sedintary in this respect, but I guess
I have a general problem with doing file I/O to get at 
something that I can just as easily get with a direct
system call.

That being said, I still think that shell tools that make
use of 'awk' and other pattern scanning tools.

Like I said,  My $0.02 worth....



Andy


> -----Original Message-----
> From: Erik Fair [mailto:fair@clock.org]
> Sent: Wednesday, March 22, 2000 2:23 PM
> To: eeh@netbsd.org
> Cc: tech-kern@netbsd.org
> Subject: sysctl(2) and/or /kern for system variable manipulation
> 
> 
> Let's entertain the /kern notion for just one more minute; assuming 
> that each object has its own permissions (which would show up as file 
> or directory permissions), then there's no problem mounting /kern 
> itself anywhere you like (indeed, it can be an unprivileged mount - 
> anyone can do it).
> 
> Now, in the case of a chroot(2)'d environment, I hear you say, "Ah 
> hah! Suppose a clever attacker gains root inside the box, and then 
> mounts /kern? He can modify various global system operational 
> parameters!"
> 
> Well, yeah. Does sysctl(2) prevent that?
> 
> What sysctl variables does one typically need inside the 
> chroot(2) box, anyway?
> 
> 8th Edition and Plan 9 have some very clever mechanisms for providing 
> for a standard, but individual execution environment by arranging the 
> filesystem name space in interesting ways with mount(2). Again, the 
> idea was simple: make almost everything into a file, and then 
> manipulate as necessary with existing tools. I think we'd do well to 
> adopt some of them, and thereby get rid of a raft of specialized 
> system calls...
> 
> 	Erik <fair@clock.org>
>