--rWhLK7VZz0iBluhq
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.
>=20
>  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?
>=20
>  Maybe you want to do privilege splitting in the application and don't tr=
ust
>  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.

--
Dan.
--rWhLK7VZz0iBluhq
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFGjd38EAVxvV4N66cRAgQ/AJ9x4SKVn1UKWAwXaLisUO5aGhFD7gCgwGTR
RqyJBNcN2QklPrwsiakgYcs=
=PKY8
-----END PGP SIGNATURE-----

--rWhLK7VZz0iBluhq--