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

[Richard Braun]

On Tue, Sep 06, 2016 at 02:49:31PM -1000, Brent W. Baccala wrote:
> 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.

We really, really don't want to make standard Unix tools aware of
Hurd-specific stuff, because that allows us to completely reuse the
work of others. With a trend towards systemd, it's even more likely
that our efforts will be put into providing some of the stuff specific
to _others_ system instead.

Personally, I would consider any solution that isn't entirely contained
in the Hurd (kernel, servers, glibc and related) to be a no-go.

> Makes sense.  The parent is where you've got all that information.  Is
> there no way to retrieve it?

There might, I haven't looked thoroughly, and it could be implemented
if needed.

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

How do you define "trusting programs". If it's the path to the binary,
then I disagree, it's far too rigid. If it's a process, and it can be
determined that this process has a property that tells us we can trust
it, then yes. The "more comprehensive" part would be what property,
and how to manipulate and check them.

I'm not sure I understand when you say "More limited in that our trust
set is finite". Actually, we'd like our trust set _not_ to be finite,
since we want the system to be extensible, by both the admin and any
unprivileged user. Again, too rigid.

Finally, I also disagree that we trust "ext2fs" or "find". We trust root.
When a program is started, it trusts the initial ports it receives. We
trust the root translator, and we trust what belongs to root inside of
it. What I want is to safely extend that trust to other users (root and
self should be default), and again, to other properties (like POSIX
style capabilities). And I'd like to merely avoid contact with servers
that aren't part of this trust computing base.

We'd also have to make sure that remove()/unlink()/rmdir() don't cross
the file system into the untrusted translator.

-- 
Richard Braun