[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hurdish applications for persistence
From: |
Jonathan S. Shapiro |
Subject: |
Re: Hurdish applications for persistence |
Date: |
Fri, 14 Oct 2005 10:14:17 -0400 |
On Fri, 2005-10-14 at 15:19 +0200, Marcus Brinkmann wrote:
> At Fri, 14 Oct 2005 14:44:49 +0200,
> Bas Wijnen <address@hidden> wrote:
> > If the chrooted filesystem contains an active translator, it will
> > (correctly)
> > have a different root. This can be used to construct communication
> > channels,
> > but I feel it would also generate accidental channels.
>
> This is always true. If you give somebody a capability that allows
> you to retrieve further capabilities, then yes, you give potentially
> all those other capabilities to the process as well.
>
> But note that if the task is confined, it can not get such a
> capability from the constructor. So, the instantiator would
> explicitely give it such a capability. You can shoot yourself in the
> foot.
Marcus has it, but here is a more precise way to state what he says:
The purpose of a chroot environment is to prevent escape. If there
existed some way to accomplish it, we would usually be happy to let the
chroot environment share **purely read only** state with our larger
environment. For example, it is silly to make multiple copies
of /bin/ls.
The only catch with purely read-only sharing is that, of course, there
will be *some* content that we do *not* want to put in the chroot
environment. So we simply shouldn't do that.
In practice, I suggest that this is a matter of configuration.
shap
- Re: Chroot and "..", (continued)
- Re: Chroot and "..", Espen Skoglund, 2005/10/13
- Re: Chroot and "..", Jonathan S. Shapiro, 2005/10/13
- Re: Chroot and "..", Alfred M\. Szmidt, 2005/10/13
- Re: Hurdish applications for persistence, Bas Wijnen, 2005/10/13
- Re: Hurdish applications for persistence, Alfred M\. Szmidt, 2005/10/13
- Re: Hurdish applications for persistence, Jonathan S. Shapiro, 2005/10/13
- Re: Hurdish applications for persistence, Bas Wijnen, 2005/10/14
- Re: Hurdish applications for persistence, Marcus Brinkmann, 2005/10/14
- Re: Hurdish applications for persistence,
Jonathan S. Shapiro <=
- Re: Hurdish applications for persistence, Alfred M\. Szmidt, 2005/10/13
- Re: Hurdish applications for persistence, Jonathan S. Shapiro, 2005/10/12
- Re: Hurdish applications for persistence, Alfred M\. Szmidt, 2005/10/13
Re: Hurdish applications for persistence, Marcus Brinkmann, 2005/10/12