From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 26 06:24:34 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEC9016A4CE for ; Thu, 26 Feb 2004 06:24:34 -0800 (PST) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3540D43D1D for ; Thu, 26 Feb 2004 06:24:34 -0800 (PST) (envelope-from ivoras@fer.hr) Received: from fer.hr (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id i1QEOVdm004566 for ; Thu, 26 Feb 2004 15:24:32 +0100 (MET) Message-ID: <403E00E6.6090505@fer.hr> Date: Thu, 26 Feb 2004 15:21:26 +0100 From: Ivan Voras User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org References: <20040226133159.GA17994@saboteur.dek.spc.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Accessing sysctls from kernel X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2004 14:24:35 -0000 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)