On Tue, Sep 6, 2016 at 2:05 AM, Richard Braun <rbr...@sceen.net> wrote:
> On Mon, Sep 05, 2016 at 09:55:44PM -1000, Brent W. Baccala wrote:
> > I haven't been able to find any other places on my system where find uses
> > -xdev; just bootclean.sh, but my search has not been exhaustive.
> >
> > Obviously there's been a long history behind this problem, and I'm new on
> > the scene. Does this change make sense?
>
> Any solution that isn't a global system solution is doomed to fail,
> since this problem may affect any RPC, including those that don't
> exist yet.
>
Let's try to hash this out, please. I've read the entire "critique" and at
least some of the prior discussion on this list. My response to it has
been, "we can work this out".
I think you have an excellent point on the need for trusted translators. I
would suggest, however, that UNIX systems already have a basic solution to
this problem - the /bin, /sbin, and /usr/bin directories. It's trivial to
write a program that looks like "rm" (or even "ls") but instead wreaks all
kinds of havoc. The hard part is getting root to run it - that's why we
don't search dot in our PATHs. It's unsophisticated, but it's simple and
usually works.
Clearly a user could fashion a translator that presented a filesystem in a
very deceptive manner to an unsuspecting superuser. Maybe we should trust
the translators in /hurd, much like we trust the binaries in /bin, and
fashion our shell prompts and directory listings so they clearly warn us
when we're dealing with a translator that isn't in that trust set.
Yet, I don't think that this is the case here.
Consider the case with symlinks. If "rm" transversed them, it could be a
big problem. Let's see... what's the option for that?... oh, there is
none! Isn't that interesting? "rm" has no option to follow symlinks!
"find" does, however. "find -L -delete" is a dangerous combination, and
when run as root will trigger the exact same behavior that we're seeing
with firmlinks in /tmp.
So, part of the solution is just making sure that the system scripts and
binaries do what we want. That "find" command used to clean /tmp should
not recurse into translators. It should delete the underlying nodes
instead.
> On a related note, how do you find the owner of a passive translator? I
> > expected either showtrans or ls to provide that information (perhaps
> with a
> > verbose switch), but it had eluded me...
>
> I'm not sure you can from outside the parent.
>
Makes sense. The parent is where you've got all that information. Is
there no way to retrieve it?
> Besides, note that Justus and I are currently pushing towards the use
> of "translator records" instead of "passive translators" to more
> accurately reflect what they truely are.
>
> The solution, whatever it is, should focus only on determining whether
> a server can be trusted or not. This should affect everything (servers,
> (active) translators and translator records).
>
Yes, we need to clearly determine when a server is trusted. Yet I think it
has to be both more comprehensive and more limited than that. More
comprehensive in that we need to determine whether programs can be trusted
as well. More limited in that our trust set is finite.
In this case, our trust set is "ext2fs", "find", and "bootclean.sh" (plus
shared libraries, the kernel, the shell, etc). We trust ext2fs to notify
us when it's handing off to a different translator. We trust "find" to
respect those notifications and not to cross those boundaries. We trust
"bootclean.sh" to clean /tmp without touching the rest of the filesystem.
This seems doable! The questions I see are, do we introduce a new switch
to find (-xtrans), and have to maintain a Hurd-specific version of
bootclean.sh, or do we overload a legacy switch (-xdev) and tolerate a more
obscure and confusing option name? Do we introduce a "-x" switch to rm, to
make "rm -rfx" avoid translators, or do we make this the default behavior,
since "rm -rf" is so ingrained into people's minds that we need to respect
its semantics?
One step at a time. Can we answer these questions, and fix our boot
sequence to properly clean /tmp?
agape
brent
