9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Russ Cox rsc@plan9.bell-labs.com
Subject: [9fans] Plan 9 future (Was: Re: Are the Infernospaces gone?)
Date: Tue,  9 May 2000 12:55:00 -0400	[thread overview]
Message-ID: <20000509165500.ETlf-rbLdMyNFYocwweD4IZ6vRDM_RPZ8EgP4RvBuIk@z> (raw)

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

How would bind(1) reproduce the structure?
Is there a way to look at the current namespace?
What if the directories I bound before have been
unmounted from where they came from?

Russ





             reply	other threads:[~2000-05-09 16:55 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-09 16:55 Russ [this message]
     [not found] <200005052042.QAA06869@er7.rutgers.edu>
2000-06-12 10:09 ` Tom E Arnold
  -- strict thread matches above, loose matches on Subject: below --
2000-05-10 12:22 rob
2000-05-10 10:17 Lucio
2000-05-10  9:49 Lucio
2000-05-10  8:51 Noel
2000-05-10  8:51 Douglas
2000-05-09 17:53 Alexander
2000-05-09 17:14 Alexander
2000-05-09 17:07 forsyth
2000-05-09 17:05 rob
2000-05-09 16:31 Alexander
2000-05-09 16:18 Alexander
2000-05-09 16:15 rob
2000-05-09 16:10 dhog
2000-05-09 14:46 Alexander
2000-05-09 11:48 forsyth
2000-05-09  8:18 Douglas
2000-05-09  8:18 Ishwar
2000-05-08 20:35 Alexander
2000-05-08 20:11 Roman
2000-05-08 16:12 Russ
2000-05-08 13:45 Lucio
2000-05-08 13:05 Bengt
2000-05-08 12:48 Lucio
2000-05-08 12:09 Leo
2000-05-08  6:56 Bengt
2000-05-08  6:28 okamoto
2000-05-08  4:34 Russ
2000-05-08  4:33 rob
2000-05-08  3:55 okamoto
2000-05-06 12:47 Steve
2000-05-06  7:28 Lucio
2000-05-06  7:04 Lucio
2000-05-05 22:00 G.David
2000-05-05 20:53 Scott
2000-05-05 20:42 Anthony
2000-05-05 17:08 Lucio
2000-05-05 16:38 Lucio
2000-05-05 15:32 forsyth
2000-05-05 14:45 Lucio
2000-05-05 14:44 jmk
2000-05-05 14:42 Lucio
2000-05-05 14:20 Lucio
2000-05-05 14:14 Lucio

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=20000509165500.ETlf-rbLdMyNFYocwweD4IZ6vRDM_RPZ8EgP4RvBuIk@z \
    --to=9fans@9fans.net \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).