From: Sargun Dhillon <sargun@sargun.me>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Linux Containers <containers@lists.linux-foundation.org>
Subject: Re: Per user rlimits
Date: Fri, 28 Aug 2020 13:33:12 -0700 [thread overview]
Message-ID: <CAMp4zn9M783PTkq0q5BV5n2x=4P4ed4F6F9b7p7ex97=_3J0GA@mail.gmail.com> (raw)
In-Reply-To: <87imd2incs.fsf@x220.int.ebiederm.org>
On Fri, Aug 28, 2020 at 12:29 PM Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
>
> Just to scope how much work it would be to fix rlimits
> so they are not a problem for user namespaces I took a quick
> survey.
>
> The rlimits can be found in
> include/uapi/asm-generic/resource.h
>
> There are a total of 16 rlimits.
> There are only 4 rlimits that are enforced at anything other
> than process granularity.
>
> RLIMIT_NPROC
> RLIMIT_MEMLOCK
> RLIMIT_SIGPENDING
> RLIMIT_MSGQUEUE
>
> So it should not be difficult to fix those rlimits.
What are your proposed semantics for what the "fix" would look like? Or
are you saying that once we take on Christian's proposal of 64-bit kuid
they would be trivial to fix? I think the reason we didn't move forward with
fixing it is the only real thing we could agree upon is an rlimit namespace,
and then you get into a question of why do these even exist, and should
they just be cgroup(v2) controllers, and should calling setrlimit just
be a wrapper around a cgroup(v2) controller that has a map of
uid -> limit?
>
> I think the implementation of RLIMIT_MEMLOCK is highly suspect, and
> might be worth reexamining, as RLMIT_MEMLOCK it interpreted differently
> in different contexts. For the limit there is mm->locked_vm,
> user->lock_vm, and user->locked_shm.
>
> Eric
>
>
>
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
next prev parent reply other threads:[~2020-08-28 20:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-28 19:25 Per user rlimits Eric W. Biederman
2020-08-28 20:33 ` Sargun Dhillon [this message]
2020-08-31 8:09 ` Aleksa Sarai
2020-08-31 8:12 ` Aleksa Sarai
2020-08-31 13:35 ` 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='CAMp4zn9M783PTkq0q5BV5n2x=4P4ed4F6F9b7p7ex97=_3J0GA@mail.gmail.com' \
--to=sargun@sargun.me \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.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;
as well as URLs for NNTP newsgroup(s).