Subject: Re: Proposal: socketfrom()
To: Darren Reed <firstname.lastname@example.org>
From: Darren Reed <email@example.com>
Date: 07/06/2007 02:23:47
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
(with varying levels of efficiency) but it'll always take more than one
If we implement a socketclone(2), then there's nothing more you can build on
top of that.