Subject: Re: Proposal: socketfrom()
To: Darren Reed <firstname.lastname@example.org>
From: Daniel Carosone <email@example.com>
Date: 07/06/2007 16:15:24
Content-Type: text/plain; charset=us-ascii
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. =20
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. =20
> > 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 tr=
> 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
Still, the point you're trying to make has merit, but so do the
principles of KISS and YAGNI.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
-----END PGP SIGNATURE-----