From: Ram <linuxram@us.ibm.com>
To: Eric Van Hensbergen <ericvh@gmail.com>
Cc: linux-fsdevel@vger.kernel.org,
Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Subject: Re: [RFC] User CLONE_NEWNS permission and rlimits
Date: Tue, 19 Apr 2005 18:50:18 -0700 [thread overview]
Message-ID: <1113961818.4920.90.camel@localhost> (raw)
In-Reply-To: <a4e6962a05041918242857271a@mail.gmail.com>
On Tue, 2005-04-19 at 18:24, Eric Van Hensbergen wrote:
> This is again related to the FUSE permission thread, but a slightly
> different idea and without a slimy hack patch.
>
> I really want to enable users to be able to create private namespaces,
> but I want to try and avoid creating a venerability by allowing them
> to abuse system resources. It looks like this can be done by adding
> RLIMIT_NEWNS as a per-user resource limit, and tracking the number of
> private namespaces a user has in the user_struct. Any time a user
> creates a private namespace (either via clone with CLONE_NEWNS) or any
> other method, this limit is checked and the per user count is
> incremented (in copy_namespace). When namespaces are cleaned up (in
> __put_namespace), the per-user count is decremented.
>
> Is this sufficient to cover any exposure? What's the correct solution
> for the shared sub-trees RFC? Should there be something similar for
> user mounts/binds?
A new namespace in a shared subtree realm can create number-of-
private-namespaces number of mounts or binds depending on the number of
binds and mounts in the shared tree.
for example if there were 10 shared vfsmounts in the original
namespace, a new private namespace will duplicate 10 of these, and
any mount or bind attempted in any of these vfsmounts will double the
number of mounts and binds.
Hence probably you may want to keep a tab on the number mounts and
binds a user does, instead of keeping a tab on the number of namespaces
a user creates.
RP
>
> -eric
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2005-04-20 1:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-20 1:24 [RFC] User CLONE_NEWNS permission and rlimits Eric Van Hensbergen
2005-04-20 1:50 ` Ram [this message]
2005-04-20 3:02 ` Ritesh Kumar
2005-04-20 3:20 ` Al Viro
2005-04-20 3:38 ` Ritesh Kumar
2005-04-20 4:01 ` Al Viro
2005-04-20 18:03 ` Bryan Henderson
2005-04-20 18:37 ` Ritesh Kumar
2005-04-20 12:47 ` Eric Van Hensbergen
2005-04-20 17:07 ` Ram
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=1113961818.4920.90.camel@localhost \
--to=linuxram@us.ibm.com \
--cc=ericvh@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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