Date: Thu, 26 Feb 2004 15:21:26 +0100 From: Ivan Voras <ivoras@fer.hr> To: hackers@freebsd.org Subject: Re: Accessing sysctls from kernel Message-ID: <403E00E6.6090505@fer.hr> In-Reply-To: <Pine.NEB.3.96L.1040226085826.79901I-100000@fledge.watson.org> References: <20040226133159.GA17994@saboteur.dek.spc.org> <Pine.NEB.3.96L.1040226085826.79901I-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > On Thu, 26 Feb 2004, Bruce M Simpson wrote: > > for consumption "on behalf" of a user process. My general preference > would be to offer an in-kernel API to manage whatever service is being > accessed if it's being done in the kernel "on behalf" of the kernel, > rather than trying to force the access through the current sysctl MIB. > That way you don't find unnecessary references to thread0, etc, which have > some dubious locking properties, as well as abuse of credentials, etc, > that may have unexpected side effects with less traditional security > models. I wholly agree with all you said, and I figured that the thread parameter is there for providing a link to the userland process, but I don't know of any alternative way to gather needed information. I would be much happier with a more simpler way to access the data (such as extern *, or a function call), but I don't know of any. Maybe a function could be added for making sysctl calls for kernel-use only? (though it may get abused for circumeventing the address space&security)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?403E00E6.6090505>