Subject: RE: sysctl(2) and/or /kern for system variable manipulation
To: 'Erik Fair' <>
From: Andy Sporner <>
List: tech-kern
Date: 03/22/2000 14:35:31

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....


> -----Original Message-----
> From: Erik Fair []
> Sent: Wednesday, March 22, 2000 2:23 PM
> To:
> Cc:
> 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 <>