From: Pavel Emelyanov <xemul@openvz.org>
To: serge@hallyn.com
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Miller <davem@davemloft.net>,
Alexey Dobriyan <adobriyan@openvz.org>,
Linux Netdev List <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] Fix /proc/net in presence of net namespaces
Date: Fri, 29 Feb 2008 11:16:13 +0300 [thread overview]
Message-ID: <47C7BF4D.6020202@openvz.org> (raw)
In-Reply-To: <20080229031737.GA3047@vino.hallyn.com>
[snip]
>> However at least for visibility and inspection we want that.
>> We want to inspect what is happening to other processes. If we didn't
>> care then all of the pid namespaces could just be disjoint.
>
> But the way Pavel has it coded, only tasks in the init namespace can
> view /proc/.net/* for any other net namespaces.
This is not essential part of the patch :) I did so to make my
life in init namespace easier. This part can be dropped.
[snip]
>> Think of user space processes inspecting /proc etc.
>
> Well a task in one pid namespace cannot view the /proc for another pid
> namespace, right?
No. Pid namespace provides another pid-to-task map, but have noting
to do with VFS visibility.
>> Having directory
>> names change out form under you for no apparent reason is pretty nasty.
>
> Yes, but they won't just 'change out' from under you, you ask for it...
> But here like I said I do prefer an approach where /proc/net is bind
> mounted by the user. But I have no good reason to back it up...
If you make /proc/net be a bund mount then you have to force all of
the users to update their init scripts. I tried to make so with sysctl
filesystem, but this thread was not very popular :)
Another way to do so - is to mount this one from inside the kernel,
but are you ready to fight with Al Viro for this? :)
[snip]
>> So I think /proc/.netns/ or simply /proc/netns/ is a good choice. We
>> just need a non-global id for our directory entries so we don't paint
>> ourselves into a corner.
>
> But I don't see how this is going to work. If you're using a pid_nr
> inside a pid namespace, then you're not guaranteeing that the pid_nr
> will be unique, so you may not be able to create th e/proc/.netns/X
> directory. If you're using the global pid, then you're not guaranteeing
> that it will be available upon a container restart.
Right - this is the same as using other ids, which I propose.
>> And honestly pid visibility is a very natural choice for which network
>> namespaces you can see. You can see the namespace of any process you
>> can see. Which especially means your children. It is an arbitrary
>> rule, it is a simple rule to explain, and it works recursively unlike
>
> But apparently not simple enough for a simpleton like me to understand,
> sorry :(
>
>> any init_net is special rule.
>>
>> Eric
>
next prev parent reply other threads:[~2008-02-29 8:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-28 15:46 [PATCH 0/2] Fix /proc/net in presence of net namespaces Pavel Emelyanov
2008-02-28 15:49 ` [PATCH 1/2] Add an id to struct net Pavel Emelyanov
2008-02-28 15:51 ` [PATCH 2/2] Make /proc/net a symlink and drop proc shadows Pavel Emelyanov
2008-02-28 19:31 ` [PATCH 0/2] Fix /proc/net in presence of net namespaces Eric W. Biederman
2008-02-28 21:17 ` serge
2008-02-28 22:39 ` Eric W. Biederman
2008-02-29 3:17 ` serge
2008-02-29 8:16 ` Pavel Emelyanov [this message]
2008-02-29 15:38 ` serge
2008-02-29 7:58 ` Pavel Emelyanov
2008-03-02 2:03 ` Eric W. Biederman
2008-03-02 2:17 ` Eric W. Biederman
2008-03-03 9:07 ` Pavel Emelyanov
2008-03-04 22:49 ` Eric W. Biederman
2008-03-05 9:43 ` Pavel Emelyanov
2008-02-29 7:44 ` Pavel Emelyanov
2008-02-29 7:42 ` Pavel Emelyanov
2008-03-02 2:29 ` Eric W. Biederman
2008-03-03 8:52 ` Pavel Emelyanov
2008-03-04 22:23 ` 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=47C7BF4D.6020202@openvz.org \
--to=xemul@openvz.org \
--cc=adobriyan@openvz.org \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=serge@hallyn.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.