Subject: Re: Proposal: socketfrom()
To: Darren Reed <>
From: Daniel Carosone <>
List: tech-net
Date: 07/06/2007 16:15:24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

Still, the point you're trying to make has merit, but so do the
principles of KISS and YAGNI.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.7 (NetBSD)