All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Stanislav Kinsbursky <skinsbursky@parallels.com>
Cc: Jeff Layton <jlayton@redhat.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH][RFC] nfsd/lockd: have locks_in_grace take a sb arg
Date: Wed, 11 Apr 2012 14:20:15 -0400	[thread overview]
Message-ID: <20120411182015.GA31025@fieldses.org> (raw)
In-Reply-To: <4F85C087.7060106@parallels.com>

On Wed, Apr 11, 2012 at 09:33:59PM +0400, Stanislav Kinsbursky wrote:
> 11.04.2012 21:20, J. Bruce Fields пишет:
> >So you really are exporting subtrees of the same filesystem from
> >multiple containers?  Why?
> >
> 
> Everything is very-very simple and obvious.
> We use "chroot jail". This is the most often and simple setup for containers.
> And, basicaly, Virtuozzo container file system consist of two parts:
> one of them is it's private modified data, another part is a
> template, used for all containers based on it (rhel6, for example;
> when it's content is modified my some container - then modified file
> copied to private part of container, which modified the file).
> Anyway, with properly configured environment it could be as many
> containers on the same file system, as possible. And making sure,
> that no data shared between them is root's responsibility.
> This approach gives us journal bottleneck. That's why, in future we
> are going to use "ploop" device (a kind of a very smart loop device)
> per container. And thus this problem with grace period for file
> systems will disappear.
> 
> >And are you sure you're not vulnerable to filehandle-guessing attacks?
> >
> 
> No, I'm not. Could you give me some examples of such attacks?

Suppose you export subtree /export/foo of filesystem /export to a
client, that client can also easily access anything else in /export; all
it hsa to do is guess the filehandle of the thing it wants to access (or
just guess filehandle of /export itself; root filehandles are likely
especially easily to guess), and then work from there.

(There's a workaround: you can set the subtree_check option.  That
causes a number of problems (renaming a file to a different directory
changes its filehandle, for example, so anyone trying to use it while it
gets renamed gets an unexpected ESTALE).  So we don't recommend it.)

So if all the containers are sharing the same filesystem, then anyone
exporting a subdirectory of its own filesystem has essentially granted
access to everyone's filesystem.

For that reason it's really only recommended to export separate
filesystems....

--b.

  parent reply	other threads:[~2012-04-11 18:20 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-03 12:14 [PATCH][RFC] nfsd/lockd: have locks_in_grace take a sb arg Jeff Layton
2012-04-09 23:18 ` J. Bruce Fields
2012-04-10 11:13   ` Jeff Layton
2012-04-10 13:18     ` J. Bruce Fields
2012-04-10 11:44 ` Stanislav Kinsbursky
2012-04-10 12:05   ` Jeff Layton
2012-04-10 12:18     ` Stanislav Kinsbursky
2012-04-10 12:16   ` Jeff Layton
2012-04-10 12:46     ` Stanislav Kinsbursky
2012-04-10 13:39       ` Jeff Layton
2012-04-10 14:52         ` Stanislav Kinsbursky
2012-04-10 18:45           ` Jeff Layton
2012-04-11 10:09             ` Stanislav Kinsbursky
2012-04-11 11:48               ` Jeff Layton
2012-04-11 13:08                 ` Stanislav Kinsbursky
2012-04-11 17:19                   ` J. Bruce Fields
2012-04-11 17:37                     ` Stanislav Kinsbursky
2012-04-11 18:22                       ` J. Bruce Fields
2012-04-11 19:24                         ` Stanislav Kinsbursky
2012-04-11 22:17                           ` J. Bruce Fields
2012-04-12  9:05                             ` Stanislav Kinsbursky
2012-04-10 20:22       ` J. Bruce Fields
2012-04-11 10:34         ` Stanislav Kinsbursky
2012-04-11 17:20           ` J. Bruce Fields
2012-04-11 17:33             ` Stanislav Kinsbursky
2012-04-11 17:40               ` Stanislav Kinsbursky
2012-04-11 18:20               ` J. Bruce Fields [this message]
2012-04-11 19:39                 ` Stanislav Kinsbursky
2012-04-11 19:54                   ` J. Bruce Fields

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=20120411182015.GA31025@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=jlayton@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=skinsbursky@parallels.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.