Daniel Carosone wrote:
> On Thu, Jul 05, 2007 at 10:17:04PM -0700, Darren Reed wrote:
> >  Daniel Carosone wrote:
> > >  - 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.
>
> Oh, I agree entirely - my objection/dislike is simply the need for
> having all that implementation at all.  
>
> I'm highlighting that what might seem otherwise like a simple proposal
> carries the implication of that extra work/code/possibility of error,
> etc. which might not otherwise be obvious.  
>
> > > 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?
> > 
> >  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?
>
> I'm not sure that's a good example: in that case you're either going
> to be passing the unpriv'd code fully-prepared and possibly connected
> fd's, even now after many set* syscalls each, or you'll pass a
> created-for-purpose template fd with nothing connected or shared in
> the original.
>
> Still, the point you're trying to make has merit, but so do the
> principles of KISS and YAGNI.
>   

Well, using the getsockopt/setsockopt approach, I can implement a 
socketclone()
(with varying levels of efficiency) but it'll always take more than one 
system call.

If we implement a socketclone(2), then there's nothing more you can build on
top of that.

Darren