LKML Archive on
help / color / mirror / Atom feed
From: Pavel Emelyanov <>
To: "Eric W. Biederman" <>
Cc:, Andrew Morton <>,
	David Miller <>,
	Alexey Dobriyan <>,
	Linux Netdev List <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH 0/2] Fix /proc/net in presence of net namespaces
Date: Mon, 03 Mar 2008 12:07:08 +0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Eric W. Biederman wrote:
> Pavel Emelyanov <> 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.

We (me) do not perform any "filtering" in /proc. I just make /proc play 
the VFS rules - one super-block one tree of dentries.

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

/proc/<pid>/mounts is not represented with any proc_dir_entry, but
what you're proposing with /proc/<pid>/net seems like doing this

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

If we're OK in having a /proc/netns/<xxx> for each namespace, then
this <xxx> is an id, regardless whatever it is - a pre-generated 
number, a pointer, etc.

That said, your only wish is to make this <xxx> be preservable across 
migration, right?

> Eric

  reply	other threads:[~2008-03-03  9:08 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
2008-03-03  9:07           ` Pavel Emelyanov [this message]
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:

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

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 0/2] Fix /proc/net in presence of net namespaces' \

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