Subject: RE: sysctl(2) and/or /kern for system variable manipulation
To: 'Erik Fair' <firstname.lastname@example.org>
From: Andy Sporner <email@example.com>
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
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
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 [mailto:firstname.lastname@example.org]
> Sent: Wednesday, March 22, 2000 2:23 PM
> To: email@example.com
> Cc: firstname.lastname@example.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
> 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 <email@example.com>