Surprise insertion of bind into namespace (anecdote)

[Ethan Grammatikidis <eekee57@fastmail.fm>]

Just noting a surprise I had with namespaces. I fixed my usage, but
thought it so surprising it ought to be shown for other namespace newbs
to see.

I wanted to bind /n/other/usr/ethan on /usr/ethan so that all dirs and
files in the former appeared in the latter; not just tmp. To do this I
simply changed the bind in $home/lib/profile, removing the "/tmp" from
both args as shown in line 4 below. 

lib/profile:
1       bind -b $home/bin/rc /bin
2       bind -b $home/bin/$cputype /bin
3       mount -qC /srv/boot /n/other other
4       bind -qa /n/other/usr/$user $home
5       bind -c $home/tmp /tmp
ns output:
1       bind -b /usr/ethan/bin/rc /bin 
2       bind -b /usr/ethan/bin/386 /bin 
3       mount -C '#s/boot' /n/other other
	bind  /usr/ethan /usr/ethan                             ←
	unrequested; breaks my namespace
4       bind -a /n/other/usr/ethan /usr/ethan 
5       bind -c /n/other/usr/ethan/tmp /tmp 

I got my dirs from /n/other, I could read and write existing files as
normal, but I could no longer create files in $home! I assumed binding
with -a would leave the original dir unaffected, but this was false.
That extra line in ns output, "bind /usr/ethan /usr/ethan", shows the
system doesn't follow this assumption; as soon as I made /usr/ethan a
mount point it implicitly lost create permissions. The fix was simple:
add "bind -bc $home $home" before line 4. Ns still shows the unrequested
bind, it appears before the "bind -bc", but apparently the -c in "bind
-bc" overrides it.

In brief: binding over a dir which is not already a mountpoint
implicitly removes create permission from that dir. Add a "bind -c $dir
$dir" to restore create permission.