Re: Hurdish applications for persistence

[ams]

   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).