netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Denis V. Lunev" <den@openvz.org>
To: Daniel Lezcano <dlezcano@fr.ibm.com>
Cc: Pavel Emelyanov <xemul@openvz.org>,
	netdev@vger.kernel.org, containers@lists.linux-foundation.org,
	benjamin.thery@bull.net, ebiederm@xmission.com
Subject: Re: [PATCH net-next] [RFC] netns: enable cross-ve Unix sockets
Date: Wed, 01 Oct 2008 18:54:45 +0400	[thread overview]
Message-ID: <1222872885.23573.64.camel@iris.sw.ru> (raw)
In-Reply-To: <48E37F1B.20601@fr.ibm.com>

On Wed, 2008-10-01 at 15:46 +0200, Daniel Lezcano wrote:
> Denis V. Lunev wrote:
> > On Wed, 2008-10-01 at 14:31 +0200, Daniel Lezcano wrote:
> >> Pavel Emelyanov wrote:
> >>>> So there are 2 cases:
> >>>>   * full isolation : restriction on VPS
> >>>>   * partial isolation : no restriction but *perhaps* problem when migrating
> >>>>
> >>>> Looks like we need an option per namespace to reduce the isolation for 
> >>>> af_unix sockets :)
> >>>>   - on (default): current behaviour => full isolation
> >>>>   - off : partial isolation
> >>> You mean some sysctl, that enables/disables this check in unix_find_socket_byinode?
> >> Yes.
> > 
> > I do not see much sense with sysctl as:
> > - check (cross-connected sockets) is required as we can start namespace
> >   with already opened socket
> 
> Check when checkpointing ? If you inherit a socket from your parent 
> namespace, this socket belongs to your parent and you should not 
> checkpoint it, no ?
> 
> In case you allow cross-connected sockets, this check is mandatory I agree.
> 
> > - this kind of sharing is not implicit but explicit as normal isolated
> >   containers _must_ have separate filesystems. In this case this
> >   sharing requires explicit host administrator action to link socket
> >   between containers
> 
> What are "normal isolated containers" ? Are they OpenVZ containers ? 
> These containers belong to the system containers family. What happens 
> with application containers, if I want to share the filesystem without 
> breaking the isolation of the afunix sockets ?

then you are doomed as you will have a FIFO opened from 2 namespaces and
checking the absences of external references is still mandatory

> The current code provides full isolation and this is in mainline. I 
> don't think it is reasonable to change that. What I propose is to keep 
> the current behaviour.
> 
> When you create a network namespace, you can change the behaviour inside 
> this namespace via /proc/sys/net/unix/isolated (for example).
> 
> This option allows:
> 1 - to connect to af_unix not belonging to the container
> 2 - to accept af_unix connection from outside the container (avoid a 
> container to forbid the checkpoint of another container);

this should be at least per/namespace option controlled from parent
container from my POW


  reply	other threads:[~2008-10-01 15:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-01 10:54 [PATCH net-next] [RFC] netns: enable cross-ve Unix sockets Denis V. Lunev
2008-10-01 11:13 ` Daniel Lezcano
2008-10-01 11:32   ` Denis V. Lunev
2008-10-01 11:55     ` Daniel Lezcano
     [not found]       ` <48E3653C.1070701-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-10-01 12:03         ` Denis V. Lunev
2008-10-01 12:19           ` Daniel Lezcano
2008-10-01 12:24             ` Pavel Emelyanov
2008-10-01 12:31               ` Daniel Lezcano
2008-10-01 12:40                 ` Pavel Emelyanov
2008-10-01 13:08                   ` Cedric Le Goater
2008-10-01 13:50                     ` Daniel Lezcano
2008-10-01 15:07                       ` Cedric Le Goater
2008-10-01 13:11                 ` Denis V. Lunev
2008-10-01 13:46                   ` Daniel Lezcano
2008-10-01 14:54                     ` Denis V. Lunev [this message]
2008-10-01 15:18                       ` Daniel Lezcano
2008-10-01 15:31                         ` Pavel Emelyanov
2008-10-01 15:38                           ` Daniel Lezcano
2008-10-01 15:42                             ` Pavel Emelyanov
2008-10-01 16:15                               ` Daniel Lezcano
2008-10-02 10:21                                 ` Denis V. Lunev
2008-10-02 20:03                                   ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1222872885.23573.64.camel@iris.sw.ru \
    --to=den@openvz.org \
    --cc=benjamin.thery@bull.net \
    --cc=containers@lists.linux-foundation.org \
    --cc=dlezcano@fr.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=netdev@vger.kernel.org \
    --cc=xemul@openvz.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).