LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Pavel Emelyanov <xemul@openvz.org>
Cc: serge@hallyn.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: Sat, 01 Mar 2008 19:17:00 -0700	[thread overview]
Message-ID: <m1zlth3m5f.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <47C7BB1B.9060906@openvz.org> (Pavel Emelyanov's message of "Fri, 29 Feb 2008 10:58:19 +0300")

Pavel Emelyanov <xemul@openvz.org> writes:

>> I was thinking we might be able to hide the existence of
>> /proc/.netns/NNN/  however we can read the current working directory.
>> So even if we only allow explicit access through /proc/net and all
>> others paths don't work we have something that is visible.
>
> I have a patch that overrides the ->readdir method for /proc/.netns,
> so that you can no longer read the directory contents, but you still
> can guess one by guessing and opening files in it. Overriding the 
> ->lookup to screw one up looks like "shadowing" technics.

Or looking at the symlinks under /proc/<pid>/fd/1
Or opening something under /proc/net/ and calling get pwd.

> OTOH - consider you have the ids of existing net namespaces, but cannot 
> read the contents on any but yours. So what? This information is useless
> for you. So I dropped this part of a patch.

However it is fundamental that monitoring programs want to inspect
the namespaces of other processes.

In theory the resource group stuff was suppose to provide us with
all of the names we would need.  However the semantics seem a bit
to flexible to use for something like this.

>> - Have readdir and lookup filter the directory entries by the pid
>>   namespace of the proc mount.
>
> So, how are you going to filter the lookup? The problem I see - you have
> a process that opened the /proc/.netns/X directory (he onws that namespace)
> and the other one trying to do the same. The VFS layer finds the hashed
> dentry corresponding to this /proc/.netns/X. The only way you can prevent
> VFS from giving one to the second task is to override .d_revalidate method 
> and drop that dentry....
>
> But we've already tried to walk this way with no luck.

I meant a per mount filtering.  Exactly like we do for the pids now.

>> It looks like we have to tweak things just a bit so that free_pid
>> would not be called until the pid namespace goes away.  Something
>> similar to how we do the hash chains.
>
> This is not about pid namespace, this is about net namespace and
> tuning pids management to facilitate networking needs is not the right
> thing to do.

Not exactly.  It is about process attribute visibility.  Which
is what proc is about.  In plan9 where the concept comes from
namespaces are referred to as process groups, and that is a valid
view.  At least from a monitoring perspective.

>> If we make namespaces show up anywhere besides under
>> "/proc/<pid>/task/<tid>/" we have to do something like this, and pids
>> are largely designed for this kind of use.
>
> Proc consists of two parts - the <pid>-s one with generated-on-the-fly
> entries and the static one that is represented by proc_dir_entry tree.
> Do you propose to mix those two?

Yes.  Because the static entries are beginning to depend on process
specific attributes.  We have already started with /proc/mounts.

>> just need a non-global id for our directory entries so we don't paint
>> ourselves into a corner.
>
> What namespace do you mean by "non-global"?

The best is an id I can take with me when I migrate from machine A
to machine B.  An id in some namespace or a form that doesn't need
an id at all is the core requirement.

Eric

  parent reply	other threads:[~2008-03-02  2:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-28 15:46 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
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 [this message]
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=m1zlth3m5f.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=adobriyan@openvz.org \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=xemul@openvz.org \
    --subject='Re: [PATCH 0/2] Fix /proc/net in presence of net namespaces' \
    /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

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).