From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue,  9 May 2000 13:14:57 -0400
From: Alexander Viro viro@math.psu.edu
Subject: [9fans] Plan 9 future (Was: Re: Are the Infernospaces gone?)
Topicbox-Message-UUID: a915cea6-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <20000509171457.TWUmXVY0FtBg2uALdFlVMi_iN_YJam91S8ckcdqoV4M@z>



On Tue, 9 May 2000, Russ Cox wrote:

>   Hmm... OK, so how do you deal with the situation when / is bound onto /mnt
>   and luser does chdir("mnt"); n times? You either have to open a DoS
>   (kernel memory exhaustion) _or_ forget what n was.
>
> You have users.  They can do whatever they want.
> The only difference between denial of service and
> legitimate use is intent.  You're trying to protect against
> things that you can't fully, at the cost of crippling
> the functionality.  There are other ways to induce
> kernel memory exhaustion too.  The only way to
> protect against all of them is to not let the users
> do anything.
>
>   ... I would like to know how do you deal with the situation described
>   above. The problem is not implementation-dependent. Again, I can provide
>   bind(1) that does the same thing as your bind(1) unless you are trying to
>   create a loop. And shell scripts don't do plain syscalls...
>
> To avoid loops, keep a hash table of where you've
> been, and don't go to places more than once.  Use
> some unique identifier (in Plan 9, the qid and mount
> point; in Linux, the inode number perhaps?).

?
Excuse me? "Don't go" as in? Again,
cat crash_it <<EOF
#!/bin/sh
cd /
while true; do cd mnt; done
EOF
chmod +x crash_it
bind / /mnt
./crash_it

- at which point is it supposed to fail and in which way?

> How would bind(1) reproduce the structure?
> Is there a way to look at the current namespace?

Currently cat /proc/mounts, but it will move into different place.

> What if the directories I bound before have been
> unmounted from where they came from?

And? You bind it from the place where it is bound _to_ and to heck
with where it came from.

Anyway, /me whistles and adds recursive bind(), which fails with -ELOOP if
you are trying to create one, clones the subtree of mount tree othervise.
There are races I don't want to think of right now and in the kernel I can
make it atomic to needed degree. I still think that it will end up in
userland, but that will require more accurate looking into the thing.

I still would like to see a use for loop-creating bind (oriented loop,
that is).