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
