From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Nikolay Borisov <kernel-6AxghH7DbtA@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
operations-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org
Subject: Re: [RFC PATCH 0/4 v3] Inotify limits per usernamespace
Date: Tue, 19 Jul 2016 19:41:07 -0500 [thread overview]
Message-ID: <87vb01dtuk.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <1468412053-30130-1-git-send-email-kernel-6AxghH7DbtA@public.gmane.org> (Nikolay Borisov's message of "Wed, 13 Jul 2016 15:14:09 +0300")
Nikolay Borisov <kernel-6AxghH7DbtA@public.gmane.org> writes:
> Hello Eric,
>
> Another day, another version...
>
> So this is version 3 of the patches initially posted at [1].
> Version 2 can be fount at [2]
>
> So I reworked the way the state for namespaces are created and
> the code is indeed a lot cleaner and easier to understand. I've
> also moved from using uid and instead always work with kuids.
> Finally I reworked the hashtable to be a global one and indexed by
> the kuid value. With this I believe I have adressed all your points
> in your previous review.
>
> I still haven't tackled the issue with the semantics of the sysctls.
> But judging from your last reply about being content with just setting
> the limit at the top-level I believe the way to fix this would be
> make a custom proc handler that writes to the variable in the
> current userns. Opinions?
So first let me say thank you for this. It was a very good starting
point for my thinking on other sysctls.
I have been proceeding on another track I will post in just a minute
that addresses some different sysctls. Those I know how to pick a
reasonable sanity check limit on a per user system wide basis and not a
per user basis so I don't have any per user limits. Otherwise it is
pretty much the same case as here.
Please take a look at those patches on how to address creating per user
namespace sysctls.
After those patches settle I will be willing to look at these more.
Eric
> [1] http://thread.gmane.org/gmane.linux.kernel/2232000
> [2] https://lists.linuxfoundation.org/pipermail/containers/2016-June/037019.html
>
> Nikolay Borisov (4):
> hashtable: Add __HASHTABLE_INITIALIZER
> misc: Rename the HASH_SIZE macro
> userns/inotify: Initial implementation of inotify per-userns
> inotify: Convert to using new userns infrastructure
>
> fs/logfs/dir.c | 6 +-
> fs/notify/inotify/inotify.h | 2 +
> fs/notify/inotify/inotify_fsnotify.c | 14 +++-
> fs/notify/inotify/inotify_user.c | 136 +++++++++++++++++++++++++++----
> include/linux/fsnotify_backend.h | 4 +-
> include/linux/hashtable.h | 3 +
> include/linux/sched.h | 4 -
> include/linux/user_namespace.h | 45 ++++++++++
> kernel/user_namespace.c | 106 +++++++++++++++++++++++-
> net/ipv6/ip6_gre.c | 8 +-
> net/ipv6/ip6_tunnel.c | 10 +--
> net/ipv6/ip6_vti.c | 10 +--
> net/ipv6/sit.c | 10 +--
> security/keys/encrypted-keys/encrypted.c | 32 ++++----
> 14 files changed, 327 insertions(+), 63 deletions(-)
prev parent reply other threads:[~2016-07-20 0:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-13 12:14 [RFC PATCH 0/4 v3] Inotify limits per usernamespace Nikolay Borisov
[not found] ` <1468412053-30130-1-git-send-email-kernel-6AxghH7DbtA@public.gmane.org>
2016-07-13 12:14 ` [PATCH 1/4] hashtable: Add __HASHTABLE_INITIALIZER Nikolay Borisov
2016-07-13 12:14 ` [PATCH 2/4] misc: Rename the HASH_SIZE macro Nikolay Borisov
2016-07-13 12:14 ` [PATCH 3/4] userns/inotify: Initial implementation of inotify per-userns Nikolay Borisov
2016-07-13 12:14 ` [PATCH 4/4] inotify: Convert to using new userns infrastructure Nikolay Borisov
2016-07-20 0:41 ` Eric W. Biederman [this message]
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=87vb01dtuk.fsf@x220.int.ebiederm.org \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=kernel-6AxghH7DbtA@public.gmane.org \
--cc=operations-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org \
/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