From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sat, 18 Oct 2008 00:26:18 -0700
From: "Roman V. Shaposhnik" <rvs@sun.com>
In-reply-to: <64debd1118fe0541e4b377bfbb18b2a2@coraid.com>
To: erik quanstrom <quanstro@coraid.com>
Message-id: <1224314778.32175.28.camel@goose.sun.com>
MIME-version: 1.0
Content-type: text/plain
Content-transfer-encoding: 7BIT
References: <26c1814ccfc8559a96987385a144c4e7@quanstro.net>
	<1224063742.4463.145.camel@goose.sun.com>
	<64debd1118fe0541e4b377bfbb18b2a2@coraid.com>
Cc: 9fans@9fans.net
Subject: Re: [9fans] several things
Topicbox-Message-UUID: 2009f108-ead4-11e9-9d60-3106f5b1d025

On Wed, 2008-10-15 at 08:17 -0400, erik quanstrom wrote:
> > > 	; mntgen a
> > > 	; bind /env a/env
> > > 	; bind /bin a/bin
> > > 	; bind /proc a/proc
> > > 	; bind a /
> > > 	; ns
> > >
> > > consider it a security feature.
> >
> > Be it as it may, I still can't quite follow why *manual* pruning
> > of the entries from the namespace would be forbidden. unmount(2)
> > takes two strings as arguments, right? It doesn't even need an fd.
>
> because they're not visible.  you have to access
> it in order to unmount it.

I see what you meant now. For some reason, I constantly assume
that namespace is sort of a substitution table that helps you
walk(5) across the bind/mount points. But it is not. Is there
a simple reason for mandating access to the target of the bind?

Or here's an easier way to ask the same: is there a simple reason
for
   $ bind /foo /really/nested/bar
always triggering walks into /foo and /really/nested/bar and not
allowing for "lazy evaluation"?

Thanks,
Roman.