From: Piotr Karbowski <slashbeast@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with
Date: Mon, 12 Dec 2022 22:55:45 +0100 [thread overview]
Message-ID: <b881d29b-4754-faa6-b50b-de2006b5783a@gentoo.org> (raw)
In-Reply-To: <robbat2-20221212T054126-100190800Z@orbis-terrarum.net>
Hi,
On 12/12/2022 06.52, Robin H. Johnson wrote:
> Please do file a bug tracking this proposal, and reference the
> discussion thread.
>
> On Sun, Dec 11, 2022 at 09:28:14AM +0100, Piotr Karbowski wrote:
>> What I'd like to do is to bump the limits.conf we ship with pam to
>> following
>>
>> * hard nproc 16384
>> * soft nproc 16384
>> * hard nofile 16384
>> * soft nofile 16384
>>
>> Those are still reasonable defaults that are much more suitable the
>> modern systems. I can only see benefits in it and am unable to think
>> about the potential drawbacks of bumping *defaults*.
> Drawbacks:
> - The "*" would apply it to all users on a system, not just the
> interactive ones, and reduce overall security posture.
> - Does this also need a sysctl change for raising fs.file-max?
>
> With those in mind, how can we deploy these defaults for interactive
> users, while still trying to maintain the good security posture overall?
>
> - Is using "@users" instead of "*" good enough? (I think yes)
> - Should it be limited to shiny logins on X or should it also take
> effect via remote logins? (conceptually yes, but I don't see a way to
> do it today within the scope of only pam_limits**)
>
>
> ** The closest other solution I can find is using a distinct limits.conf
> for interactive logins, selected via pam.d trickery, and I don't like
> that proposal.
Since both you and Sam requested bug[1], so be it -- though I still find
it excessive and I do not remember any other case where discussion about
change in package were tracked in bug, I just hope it will not branch
discussion to be in two places, navigating it would be difficult.
Looks like I have some backtracking to do. I pulled off latest stage3
and seems like the limits.conf there have no entries by default, I do
however have the nproc limit there on 2 old gentoo systems dating back
into 2009, perhaps at some point limits.conf have it and I do not
remember adding it there, so either it could be default at some point in
time, or I added it and forgot, with the later being more likely.
Apologies for confusion.
Regardless I'd like to continue the discussion about the new Gentoo's
defaults.
Which makes the current defaults being inherited from kernel, though pid
1 to all the children, which are
For the 32bit x86:
limit soft hard
nproc 64095 64095
nofile 1024 4096
And for the 64bit x86
limit soft hard
nproc 256819 256819
nofile 1024 4096
The fs.file-max does not need any change, on 32bit x86 it's 1636118 and
on 64bit x86 it's 6574089
What I propose here is to significantly bump the limit of open files per
user, and limit the number of PIDs per user to 16k. If anything, the
current defaults allow you to make a DoS by forkbomb, the current
defaults are neither secure nor make sense in 2022. Linux kernel is full
of defaults that beg to be updated, among others, vm.swappiness makes
absolute no sense in its current defaults either.
As for the remote logins, local logins and X sessions -- I see no value
in having different limits across those.
[1] https://bugs.gentoo.org/885589
-- Piotr.
next prev parent reply other threads:[~2022-12-12 21:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-11 8:28 [gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with Piotr Karbowski
2022-12-11 12:46 ` Sam James
2022-12-11 15:38 ` Piotr Karbowski
2022-12-12 5:52 ` Robin H. Johnson
2022-12-12 21:55 ` Piotr Karbowski [this message]
2022-12-12 22:06 ` Sam James
2022-12-12 22:26 ` Piotr Karbowski
2022-12-12 22:53 ` Sam James
2022-12-13 3:24 ` John Helmert III
2022-12-13 5:18 ` Joonas Niilola
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=b881d29b-4754-faa6-b50b-de2006b5783a@gentoo.org \
--to=slashbeast@gentoo.org \
--cc=gentoo-dev@lists.gentoo.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