Thor Lancelot Simon <tls@rek.tjls.com> writes:

> On Fri, Dec 02, 2005 at 09:42:09AM -0500, Steven M. Bellovin wrote:
> > In message <mtuvey7wp9p.fsf@contents-vnder-pressvre.mit.edu>, "Nathan J. Willia
> > ms" writes:
> > >Elad Efrat <elad@NetBSD.org> writes:
> > >
> > >> We use sysctl(3) outside sysctl(8) a lot. Recent examples: using sysctl
> > >> for reading inet/inet6/local PCBs and protocol statistics instead of
> > >> using /dev/kmem; rpaulo@ even made trpt/trsp use sysctl, which means we
> > >> don't have to give them the sgid kmem bit anymore.
> > >
> > >I object to those, too.
> > >
> > 
> > I don't -- cleaning up kmem grovelers is a good idea.  Sysctl may not 
> > be the best mechanism, but it's far from the worst.

Just so I'm clear, this is a side issue, yes? There's no kmem
grovelling involved in veriexec?

> A lot of the time, when this functionality migrates into sysctl namespace
> the major benefit is that because of the way sysctl is implemented, it's
> harder to implement bulk access to huge swaths of data than to actually
> think through what must be visible or modifiable and implement access to
> just that.  *That* is the real benefit: an explicitly typed interface
> rather than the "read stuff and apply types to it yourself" interface
> implemented via /dev, or the somewhat clumsy interfaces that try to
> describe the underlying data using ioctl -- sysctl is better here, I
> think, because it's *consistent* instead of a million underlying roll-
> your-own takes on doing this with ioctl.
> 
> I still think the _names_ for these things belong in the filesystem and
> that they should have filesystem permissions, but I am not sure we should
> use standard filesystem system calls (not even ioctl) to operate on them.
> I think that would pretty much give us the best of both worlds.  These are
> *not* bytestreams and we should *not* treat them as such, as myriad bugs
> and security holes have taught us again and again over time.

I agree that the namespace and access control should be in the
filesystem; that's what drives a lot of my annoyances about sysctl().

I guess I'm less convinced by the idea that sysctl(), when used this
way, is more strongly typed than an ioctl(); in both cases, we're
talking about passing binary structures between userland in the
kernel. I'll agree that it's easy to abuse read() and write() on /dev
nodes, but again, there's a level at which it's all just structures.

        - Nathan