Re: [gentoo-dev] pam: thoughts on modernizing pam_limits configuration that Gentoo ships with

[Sam James <sam@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]



> On 12 Dec 2022, at 21:55, Piotr Karbowski <slashbeast@gentoo.org> wrote:
> 
> 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.
> 

It's unusual to have discussion about a single package on the mailing lists. I tend to keep an eye on PAM
bugs because I maintained pambase.

Bugs are the primary method of discussing changes to packages.

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]