| 1 |
> On 12 Dec 2022, at 21:55, Piotr Karbowski <slashbeast@g.o> wrote: |
| 2 |
> |
| 3 |
> Hi, |
| 4 |
> |
| 5 |
> On 12/12/2022 06.52, Robin H. Johnson wrote: |
| 6 |
>> Please do file a bug tracking this proposal, and reference the |
| 7 |
>> discussion thread. |
| 8 |
>> On Sun, Dec 11, 2022 at 09:28:14AM +0100, Piotr Karbowski wrote: |
| 9 |
>>> What I'd like to do is to bump the limits.conf we ship with pam to |
| 10 |
>>> following |
| 11 |
>>> |
| 12 |
>>> * hard nproc 16384 |
| 13 |
>>> * soft nproc 16384 |
| 14 |
>>> * hard nofile 16384 |
| 15 |
>>> * soft nofile 16384 |
| 16 |
>>> |
| 17 |
>>> Those are still reasonable defaults that are much more suitable the |
| 18 |
>>> modern systems. I can only see benefits in it and am unable to think |
| 19 |
>>> about the potential drawbacks of bumping *defaults*. |
| 20 |
>> Drawbacks: |
| 21 |
>> - The "*" would apply it to all users on a system, not just the |
| 22 |
>> interactive ones, and reduce overall security posture. |
| 23 |
>> - Does this also need a sysctl change for raising fs.file-max? |
| 24 |
>> With those in mind, how can we deploy these defaults for interactive |
| 25 |
>> users, while still trying to maintain the good security posture overall? |
| 26 |
>> - Is using "@users" instead of "*" good enough? (I think yes) |
| 27 |
>> - Should it be limited to shiny logins on X or should it also take |
| 28 |
>> effect via remote logins? (conceptually yes, but I don't see a way to |
| 29 |
>> do it today within the scope of only pam_limits**) |
| 30 |
>> ** The closest other solution I can find is using a distinct limits.conf |
| 31 |
>> for interactive logins, selected via pam.d trickery, and I don't like |
| 32 |
>> that proposal. |
| 33 |
> |
| 34 |
> 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. |
| 35 |
> |
| 36 |
|
| 37 |
It's unusual to have discussion about a single package on the mailing lists. I tend to keep an eye on PAM |
| 38 |
bugs because I maintained pambase. |
| 39 |
|
| 40 |
Bugs are the primary method of discussing changes to packages. |
Archives