At Tue, 08 Aug 2006 00:28:33 +0200, "Ernst Rohlicek jun." <[EMAIL PROTECTED]> wrote: > Persistence: Well, I'm not sure whether orthogonal persistence (in my > interpretation this is quite similar to hiberation / suspend to disk) is > really required - better: what it's benefits in a general-purpose OS for > non-embedded CPUs are... > > After all you can still store your caps on disk, if you would like to.
You can, but if you do not save all the state, but only part of it, you face the non-trivial question which state to save and how to reconstruct the state that you don't safe (if it needs to be reconstructed). Clearly most of the state in your machine at any given time is junk. If you tell me which 90% of it is junk, I'd be very happy to drop the rest. So, to answer this question, we need to look at all the state and need to be able to label it with "save this" or "don't save this". Case in point: The Hurd passive translators are supposed to capture the state of a server in a command line string associated with an inode (the "name server entry" if you want). But in the current implementation, this fails to capture the complete state of the server process. This allows for rather simple attacks to escape a chroot environment, for example (because the filesystem jail of the server process is not captured state), and the system will reconstitute it with the wrong value). Of course, in the current implementation, we do not have any feature to save capabilities to disk at all. Capabilities are reconstructed from the user ID using the auth server (the filesystem stores user IDs with inodes to control privilege to reconstitute capabilities). This gives us the problems associated with ACLs. But being able to store capabilities is just a technical requirement for a solution, not the solution itself. The real problem lies in identifying the state that needs to be captured, not how to capture it technically. It's semantics, not syntax. I am not saying it's an impossible problem. It doesn't need to be. But it is not clear to me which solution is actually simpler. May depend on other parts of the design (features, etc). Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
