public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrei Vagin <avagin@virtuozzo.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: <avagin@openvz.org>, <containers@lists.linux-foundation.org>,
	<linux-kernel@vger.kernel.org>,
	Serge Hallyn <serge.hallyn@canonical.com>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 0/2 v2] userns: show current values of user namespace counters
Date: Mon, 10 Oct 2016 09:22:03 -0700	[thread overview]
Message-ID: <20161010162202.GA31628@outlook.office365.com> (raw)
In-Reply-To: <87wphlclwe.fsf@x220.int.ebiederm.org>

On Thu, Oct 06, 2016 at 02:33:53PM -0500, Eric W. Biederman wrote:
> Andrei Vagin <avagin@virtuozzo.com> writes:
> 
> > Hello Eric,
> >
> > What do you think about this series? It should be useful to know current
> > usage for user counters.
> 
> I am in favor of knowing the values.  Unless there is a good reason not
> to we should export the values with a read-only sysctl.  I believe that
> is what other similar limits do.

I want to have a place where I will be able to get limits for all
users. I can't imagine how to do this with a sysctl. It will looks like
multiline sysct-s, what doesn't look good. I will think. If you will
have any ideas let me know. Thanks.

> 
> As for having per process knowledge I think that is probably something
> we want to solve for these sysctls as well.
> 
> I don't think I saw anyone looking at this code from the perspective of
> information leaks.  I think we need to ask that question, as similar
> interfaces have been problematic from an information leak point of view.

It's a good question.

> 
> In short I what you are trying to do here is valuable, I just want
> to make certain we have a maintainable pattern when we export these.
> 
> Eric
> 
> >
> > Thanks,
> > Andrei
> >
> > On Mon, Aug 15, 2016 at 01:10:20PM -0700, Andrei Vagin wrote:
> >> Recently Eric added user namespace counters.  User namespace counters is
> >> a feature that allows to limit the number of various kernel objects a
> >> user can create. These limits are set via /proc/sys/user/ sysctls on a
> >> per user namespace basis and are applicable to all users in that
> >> namespace.
> >> 
> >> User namespace counters are not in the upstream tree yet,
> >> you can find them in Eric's tree:
> >> https://git.kernel.org/cgit/linux/kernel/git/ebiederm/user-namespace.git/log/?h=for-testing
> >> 
> >> This patch adds /proc/<pid>/userns_counts files to provide current usage
> >> of user namespace counters.
> >> 
> >>   > cat /proc/813/userns_counts
> >>   user_namespaces          101000               1
> >>   pid_namespaces           101000               1
> >>   ipc_namespaces           101000               4
> >>   net_namespaces           101000               2
> >>   mnt_namespaces           101000               5
> >>   mnt_namespaces           100000               1
> >> 
> >> The meanings of the columns are as follows, from left to right:
> >> 
> >>   Name         Object name
> >>   UID          User ID
> >>   Usage        Current usage
> >> 
> >> The full documentation is in the second patch.
> >> 
> >> v2: - describe this file in Documentation/filesystems/proc.txt
> >>     - move and rename into /proc/<pid>/userns_counts
> >> 
> >> Cc: Serge Hallyn <serge.hallyn@canonical.com>
> >> Cc: Kees Cook <keescook@chromium.org>
> >> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> >> Signed-off-by: Andrei Vagin <avagin@openvz.org>
> >> 
> >> Andrei Vagin (1):
> >>   kernel: show current values of user namespace counters
> >> 
> >> Kirill Kolyshkin (1):
> >>   Documentation: describe /proc/<pid>/userns_counts
> >> 
> >>  Documentation/filesystems/proc.txt |  30 +++++++++++
> >>  fs/proc/array.c                    |  55 ++++++++++++++++++++
> >>  fs/proc/base.c                     |   1 +
> >>  fs/proc/internal.h                 |   1 +
> >>  include/linux/user_namespace.h     |   8 +++
> >>  kernel/ucount.c                    | 102 +++++++++++++++++++++++++++++++++++++
> >>  6 files changed, 197 insertions(+)
> >> 
> >> -- 
> >> 2.5.5

  reply	other threads:[~2016-10-10 18:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-15 20:10 [PATCH 0/2 v2] userns: show current values of user namespace counters Andrei Vagin
2016-08-15 20:10 ` [PATCH 1/2] kernel: " Andrei Vagin
2016-08-16 20:00   ` Kees Cook
2016-08-16 20:05     ` Serge E. Hallyn
2016-08-16 22:44       ` Andrei Vagin
2016-08-15 20:10 ` [PATCH 2/2] Documentation: describe /proc/<pid>/userns_counts Andrei Vagin
2016-08-16 22:53 ` [PATCH 0/2 v2] userns: show current values of user namespace counters Serge E. Hallyn
2016-10-06 17:51 ` Andrei Vagin
2016-10-06 19:33   ` Eric W. Biederman
2016-10-10 16:22     ` Andrei Vagin [this message]
2016-10-10 20:44       ` Eric W. Biederman

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=20161010162202.GA31628@outlook.office365.com \
    --to=avagin@virtuozzo.com \
    --cc=avagin@openvz.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=serge.hallyn@canonical.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox