Re: fexecve, round 3

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Mon, Nov 26, 2012 at 03:22:42AM +0100, Emmanuel Dreyfus wrote:
> David Laight <david%l8s.co.uk@localhost> wrote:
> 
> > Given a chrooted process would need a helping process outside the
> > chroot (to pass it the fd), why is allowing the chrooted proccess to
> > exec something any different from it arranging to get the helper
> > to do it?
> 
> Yes, I agree there is no security hazard introduced: if help from a
> process outside the chroot is assumed, there are already many ways to
> cirumvent chroot security.

And I strongly disagree.  We've discussed this at painful length in
the earlier threads on this topic and I don't really, at this time,
want to restate the entire discussion; nor do I think I should need to.

I think this is an unfortunate effect of the way we are discussing
this ("round 1", "round 2", "round 3", each as a separate thread
starting with a call for anyone objecting to restate their objections
to this code going into the tree).  There have been many objections,
some subtle and not trivial to restate, and much discussion besides
of the broken nature of this specification itself.  Why must we go
'round in circles?  NetBSD's only blanket statement on standards
conformance of which I am aware is that NetBSD tries to confirm to
"reasonable" standards, specifically calling out the ancestor of
the standard we're talking about here as an "unreasonable" one.

Why should this discussion take place under what seems to be the
basic assumption that if those opposed to this code going into
the tree can simply be forced to talk until they're sick of talking
any more, these interfaces should go into the tree because they're
(poorly) described in some standard, somewhere?  That seems wrong.

Thor