Scribit [EMAIL PROTECTED] dies 27/03/2008 hora 02:28:
> > The problem here is that authority is given instead of demonstrated.
> > No translator should receive a port from a priviledged server like
> > the parent FS server.
> Sorry, that's too abstract for me...
This is a classical example of conf
Hi,
On Wed, Mar 19, 2008 at 08:13:02PM +0100, Pierre THIERRY wrote:
> Scribit [EMAIL PROTECTED] dies 19/03/2008 hora 17:04:
> > The problem is that passive translators are started by the parent
> > filesystem server to which they are attached, not by the process
> > accessing the node; thus they
Scribit [EMAIL PROTECTED] dies 19/03/2008 hora 17:04:
> The problem is that passive translators are started by the parent
> filesystem server to which they are attached, not by the process
> accessing the node; thus they get a "normal", non-chrooted port, and
> consequently have access to the whole
Hi,
On Wed, Mar 19, 2008 at 02:15:22AM +0100, Pierre THIERRY wrote:
> Scribit [EMAIL PROTECTED] dies 18/03/2008 hora 16:38:
> > Now the problem is that a chrooted process can create a passive
> > translator. When this translated node is accessed, the translator
> > process currently won't be star
Hi,
On 3/18/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > I also find "secure chroot implementation" in the list. IMHO, the
> > unsafty of chroot is not caused by passive translator. In fact,
> > currently chroot is implemented totally at client side by changing the
> > INIT_PORT_CRDIR po
Scribit [EMAIL PROTECTED] dies 18/03/2008 hora 16:38:
> Now the problem is that a chrooted process can create a passive
> translator. When this translated node is accessed, the translator
> process currently won't be started in the context of the chrooted
> process, but in that of the normal global
