Re: Hurdish applications for persistence

[Alfred M\. Szmidt]

   You claim so, but you offer no pudding.  

I prefer to keep my pudding to my self.  Anyway, you can use fchdir(),
various forms of ../, and recursive chroots.  And I would have
suggested mknod(), but see bellow..

   Tell me how a non-root user can escape a chroot that contains no
   device nodes, and no suid binaries on the latest versions of the
   following systems:

Since abusing device nodes is similar to abusing firmlinks, one could
simply not provide settrans in a chroot.  Given mknod, one can escape
chroot, and given firmlink/settrans, one can also escape a chroot by
doing the same thing.

You could for example solve the whole mess about chroots by making the
chroot ro, and then making one single directory writable, but
disallowing running programs. (this could be implemented with
translators sitting on top of a node, and passing through all calls to
the underlying file-system, and then simply ignoring whatever they are
supposed to ignore)

If you can put a random program in a chroot, you will _always_ find a
way to break out of it.  And it is simply not worth fixing it.

   I have elaborated at length why the chroot _example_ matters well
   beyond the use of chroot.  I thought, and still think, that the
   example is a good lever to help to understand the critical problem
   of (preserving) the execution environment of servers, and the
   question of confinement.

And I still consider chroot as a bad example, and consider sub-hurds
(or some form of them) far more flexible than chroot().

   I don't think it is possible to fix passive translators in the
   Hurd.

The thing is that I don't think it is worth the trouble to fix them.
It is to much of a headache, and it doesn't give you that much anyway,
since you can solve the problems that come with passive translators in
other ways that are simpler.