Subject: Re: Proposal: socketfrom()
To: Darren Reed <firstname.lastname@example.org>
From: Darren Reed <email@example.com>
Date: 07/05/2007 22:17:04
Daniel Carosone wrote:
> On Thu, Jul 05, 2007 at 08:51:06PM -0700, Darren Reed wrote:
> > The idea with most merit that I've seen is to be able to save and
> > restore socket option state. Save it into a binary blob using a call
> > to getsockopt() and apply it to another with setsockopt().
> I don't really like this idea, for a couple of reasons:
> - the "opaque blob" may be manipulated by a malicious program, we
> need to be defensive about not trusting the content in the kernel
> once it's handed back to us.
It is the job of the implemtation of whatever takes in the blob
to verify it. How is this blob any different to, say, a struct
sockaddr, or a BPF program or...?
> - to try and avoid this, if the blob is to be a reference to some
> other storage in the kernel where the real data is, we now have
> another namespace, maybe more interface to manipulate the options
> stored in the blobs, we have storage management to deal with, etc.
You're judging the implementation before it has been prototyped.
> Frankly, if you're going to pass something to represent a set of
> options to copy, why not just pass the fd of the socket that has
> those options set? That seems like the place to store them without
> any of the above issues (or at least, well defined semantics and
> tested implementations of those issues :-).
Maybe you want to do privilege splitting in the application and don't trust
the "other part" that deals with the "clone" fd's to access the original?
> The question then becomes where to put the operation that does this
> - in a new syscall, as Thor proposes, though I prefer socketlike() as
> a name, and with the single argument.
I've yet to see any generality to this system call that makes it
anything other than a hack to solve Thor's problem. Those
kinds of things belong in ThorBSD.