I don't see what file_reparent has to do with it, you would have to explain that to me.
Neither do I right now... I'm quite sure I had a reason to mention it.. Also, if you think it is just an exploit in the implementation, and not a design flaw, you will surely have a way in mind to fix the implementation. Please share that with us. I am very interested to hear about it. Well, since chroot is inherently unsecure on all platforms (chroot was never designed to be secure!), it would be simpler to deprecte it and come up with another scheme. What the exact scheme is, I do not know yet, but something like sub-hurds. Let's say you remove chroot from the system, and all related code. I suppose that's what you want to do if you think that chroot should not be used (leaving an exploitable chroot implementation in the code is clearly suboptimal). Indeed that it is suboptimal. Then you have reintroduced the single global namespace that Unix has, and you have just removed security, and not added to it: All files are accessible to all programs. I fail to see how this has been reintroducded, sub-hurds don't have the same global namespace. So, getting rid of chroot is exactly the wrong way to go about it. I disagree. There is no reasonable way to share resources between the Hurd and a subhurd (actually, there is a way: Then such a means should be implemented, some kind of a proxy translator where you specify what resources you can use from within the sub-hurd (think firewall). _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
