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)
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
