Date: Mon, 25 Mar 2019 22:34:19 -0400 From: Mark Johnston <markj@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Warner Losh <imp@bsdimp.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Alfonso Siciliano <alfix86@gmail.com> Subject: Re: kern_sysctl.c interface Message-ID: <20190326023419.GB62914@raichu> In-Reply-To: <885.1552506820@critter.freebsd.dk> References: <20190313013530.d96fc84c362bb489178357eb@gmail.com> <78358.1552464694@critter.freebsd.dk> <CANCZdfo8v6O%2BcJqOFu87ReiTTJxQJxX8YZgj8RBygy9Nb_FEEw@mail.gmail.com> <885.1552506820@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 13, 2019 at 07:53:40PM +0000, Poul-Henning Kamp wrote: > -------- > In message <CANCZdfo8v6O+cJqOFu87ReiTTJxQJxX8YZgj8RBygy9Nb_FEEw@mail.gmail.com> > , Warner Losh writes: > > >> > * This interface is under work and consideration, and should probably > >> > * be killed with a big axe by the first person who can find the time. > >> > * (be aware though, that the proper interface isn't as obvious as it > >> > * may seem, there are various conflicting requirements. > >> > >> I think that is a comment I added more than 20 years ago because we, > >> or at least I, wondered if the sysctl-OID tree should be moved to > >> something SNMP-OID compatible. > >> > >> I dont know of anything happening after that. > > > >I suspect after 20ish years the comment can be removed, eh? > > Well, it's still a butt-ugly and inefficient interface... I don't know that it'd help much with efficiency, but lately I've wanted an fd-based interface for sysctl so as to be able to use Capsicum to restrict the sysctl namespace. The idea is that a sysctlfd would reference a node in the sysctl hierarchy, and it would be possible to read or write a descendent node using the relative sysctlfd, like the *at() system calls. Only sysctls reachable from an open sysctlfd could be accessed while in capability mode. Today, we have a situation where sysctls are either statically flagged as CTLFLAG_CAPRD and thus are readable in capability mode, or you have to talk to another process over a unix socket and have it access the sysctl on your behalf. I'm not sure what an ideal syscall interface for this would look like. I think you could probably implement the idea using the existing __sysctl() syscall, by having a magic OID that writes an fd to the out buffer. Ideally you'd be able to use relative names to refer to sysctl, so that if you had an fd for dev.cpu, you could read CPU 0's temperature with something like: sysctlat(cpufd, "0.temperature", oldp, &oldlen, NULL, 0); That could avoid resolving "dev.cpu" each time it's read, so it'd be more efficient than what we do today. A real interface has to handle iteration and name resolution (hopefully avoiding an extra syscall just for resolution). It also needs to handle sysctl nodes that are addressed by OID, like kern.proc.pid.<pid>.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190326023419.GB62914>