Date: Thu, 26 Feb 2004 09:01:49 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Bruce M Simpson <bms@spc.org> Cc: Ivan Voras <ivoras@fer.hr> Subject: Re: Accessing sysctls from kernel Message-ID: <Pine.NEB.3.96L.1040226085826.79901I-100000@fledge.watson.org> In-Reply-To: <20040226133159.GA17994@saboteur.dek.spc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 26 Feb 2004, Bruce M Simpson wrote: > On Thu, Feb 26, 2004 at 02:10:40PM +0100, Ivan Voras wrote: > > In sys/sys/sysctl.h I see function kernel_sysctlbyname() that looks (to > > me) to be intended for accessing sysctl values from kernel, but for it's > > first parameter it requires a struct thread *td. > > > > What should I pass to it? (I'm calling it from inside a screensaver module) > > You could try lying about which thread you are, when you aren't in a > userland thread: > > Cscope tag: kernel_sysctlbyname > # line filename / context / line > 1 728 /sys/dev/vinum/vinumio.c <<vinum_scandisk>> > error = kernel_sysctlbyname(&thread0, "kern.disks", NULL, > 2 741 /sys/dev/vinum/vinumio.c <<vinum_scandisk>> > kernel_sysctlbyname(&thread0, "kern.disks", devicename, > 3 305 /sys/i386/i386/elan-mmcr.c <<init_AMD_Elan_sc520>> > i = kernel_sysctlbyname(&thread0, "machdep.i8254_freq", FWIW, the thread exists in the context of a sysctl for several reasons -- one is to provide access to the requesting process's address space, another is the credential authorizing the change. While there are calls kernel_sysctl() and kernel_sysctlbyname(), those are generally intended 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. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040226085826.79901I-100000>