>> 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.

I don't consider this a big deal.  If the opaque blob format is
suitably designed and its handling code is sensible, handing arbitrary
blobs to the kernel cannot do anything that making equally arbitrary
calls to setsockopt couldn't; I see no particular hazard there.  The
only difference would be one kernel/user crossing for the whole setting
operation instead of one per option.

I'm thinking something like array of packed struct { unsigned char opt;
int value; } (mutatis mutandis for options not using int), though of
course the details would be private to the kernel.  If the kernel finds
an invalid option, or value, in the blob, it would fail the set call,
just as it would a setsockopt call that got passed similar garbage.

>  - 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, [...]

Oh, ugh.  I like that about as much as you seem to.  :-þ

> 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?

It requires that that socket still exist.  I see no particular reason
to demand one file descriptor be kept open per set of options, rather
than storing just the useful information.

I see no particular reason *not* to provide such an interface, though.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B