Subject: Re: Proposal: socketfrom()
To: Darren Reed <email@example.com>
From: Daniel Carosone <firstname.lastname@example.org>
Date: 07/06/2007 14:43:27
Content-Type: text/plain; charset=us-ascii
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().=20
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.
- 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.
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 :-).
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.
- in setsockopt(), with a new variant/magic option that says "make
the options on this socket the same as that socket" and takes
another fd-number as the parameter.
- in the user program, with a different get/setsockprops() interface=20
(and a blob format whose opacity is the subject of endless debate :)
I like the first as a direct response to the immediate requirement,
but the second or third are more flexible/extensible, in that it could
be applied to existing sockets as well as just at the creation of new
ones, at the cost of one extra syscall in Thor's (and perhaps the most
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
-----END PGP SIGNATURE-----