Re: rm patch suggestion

[Roland McGrath]

> Oh, and then
> 
> settrans --chroot rm -rf / -- /tmp/untrusted /hurd/safety
> 
> with a wrapper script "safety" like for fakeroot?

You could do that.  Users might want to operate that way for a variant that
trusts that user as well as root.  It reduces duplication and keeps things
simpler to just permanently install a translator, e.g. on /secure and just
use "chroot /secure".  Things like sudo might do that themselves.  This
could still be a false sense of security if one ever runs setuid binaries,
though (since they will revert to the global standard root port).

> Sounds like a pattern :)

"Solve problems with creative use of filesystem translators"?  Well, yeah...

> I think the only headache would be filesystems that refuse to go away
> easily.  Maybe that's something the -f option could do: if the node is
> translated (assuming you see this, for example because of the safety
> translator above), then try to get rid off the translator as hard as
> possible, like the -f flag on settrans).

I don't think this is a problem, except for rmdir.  If it is, I think the
"safety" translator's unlink and rmdir calls (and rename, which can unlink
an old node under the new name) should behave specially too.  But in fact I
think nothing is necessary to work as well as settrans --orphan for unlink.
The parent filesystem unlinks the underlying node, and that is that--there
is no longer a new way to get to the translator; it sends the translator an
fsys_goaway, but does not care about the reply.  

For rename, it is not entirely consistent--that is, it never sends
fsys_goaway.  I think this is a bug.  The rename case is the same code path
as the case of the underlying node being open when it's unlinked (so
st_nlink goes to zero), and later being closed.  The translator is not
notified or detached, even though there is no longer any way to get to it.
I think that rename should be consistent with unlink, i.e. check for
st_nlink == 0 and send fsys_goaway with FSYS_GOAWAY_UNLINK.

For rmdir, it will just not let you do it.  That is, it returns EBUSY if
the node has a translator (even just a passive translator).  This is done
safely, i.e. without talking to the translator at all.  So the safety
translator could check for EBUSY from rmdir and react by clearing the
translator and repeating the rmdir.  Another reasonable thing would be to
give the dir_rmdir RPC a FSYS_GOAWAY_* flags argument where
FSYS_GOAWAY_DONT means the current behavior.

> Which reminds me, there are still some translators in the Hurd that don't
> obey to the standard rules for this (mostly obscure specialised
> translators), that's also a nice job for new Hurd hackers to fix.

I'm not following what you are referring to here.