On 10/16/18 6:25 AM, Kamil Paral wrote:
On Mon, Oct 15, 2018 at 7:34 PM Lennart Poettering <mzerqung@xxxxxxxxxxx <mailto:mzerqung@xxxxxxxxxxx>> wrote:On Mo, 15.10.18 18:00, Kamil Paral (kparal@xxxxxxxxxx <mailto:kparal@xxxxxxxxxx>) wrote: > On Tue, Oct 9, 2018 at 6:15 PM Lennart Poettering <mzerqung@xxxxxxxxxxx <mailto:mzerqung@xxxxxxxxxxx>> > wrote: > > > On Di, 09.10.18 14:45, Anderson, Charles R (cra@xxxxxxx <mailto:cra@xxxxxxx>) wrote: > > > > > > It would be nice if somebody managed to find where this is patched in > > > > Debian. Because I somewhat doubt that they made this change without a > > > > proper discussion. And Debian is very much server oriented. > > > > > > Can we not have the RPM package drop a file in /etc/security/limits.d > > > to set the limit only when that package is installed? That way it > > > only affects users of that package. > > > > That only affects stuff that goes through PAM (specifically, all PAM > > stacks that include pam_limits.so). > > > > It is my intention to change this system wide, i.e. for system > > services (which do not go through PAM) too. > > > > Lennart, what is the path forward here? Should we pull in some security > experts to give us recommendations on the best default value? Or are those > conversations already happening somewhere else? Also, do you need any more > information regarding the Wine esync use case, or has Zebediah provided > sufficient data? Please follow the current state of this here: https://github.com/systemd/systemd/pull/10244 I have been discussing with some upstream kernel folks, and some more obstacles showed up (specifically, I was advised that we really should bump fs.file-max and fs.nr_open sysctls to their maximums these days, as these limits are not really useful anymore given that fd memory is properly tracked by memcg anyways these days), which I have now covered in the PR above. This is waiting for review, but should enter systemd upstream soon, and will then eventually trickle into Fedora.Zebediah, do you know about any other outlier except of Google Earth VR for which the newly proposed default limit of 256K wouldn't be sufficient?
I do not, no. That number came up pretty early in testing, and I think we ended up leaving the limit at ~1M while testing other applications. On the other hand, I know many users in the wild have used ~200k values, and I haven't heard anyone specifically say that wasn't enough.
Security concerns aside, I'm all in favor of pushing the solution farther upstream.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
