bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: firmlink deleting files on boot / interpretation of find -xdev switc


From: Brent W. Baccala
Subject: Re: firmlink deleting files on boot / interpretation of find -xdev switch
Date: Tue, 6 Sep 2016 14:49:31 -1000

On Tue, Sep 6, 2016 at 2:05 AM, Richard Braun <rbraun@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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]