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?

Who knows.

> The question then becomes where to put the operation that does this
> copying:
>
>  - 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.

Darren