Description of problem: The 2.6 kernel supports two new limits, RLIMIT_SIGPENDING and RLIMIT_MSGQUEUE. Supporting them is potentially really important some applications might not run with the default limits and on many-user machines the defaults are likely too high. Version-Release number of selected component (if applicable): pam-0.77-54 How reproducible: always Steps to Reproduce: 1.well, read PAM docs and sources 2. 3. Actual results: Support not there Expected results: Support sigpending and mqueue limits Additional info: bash-3.0-8 has support for these limits so checking whether the code works is easy.
Created attachment 108984 [details] adds sigpending and mqueue params to pam_limits hi, here's a patch that adds two parameters to pam_limits.c so you can set the limits on pending signals and POSIX queue memory. It applies against 0.77 (which is what my system is running) but looks like it should apply against 0.78 also.
Created attachment 108985 [details] adds sigpending and mqueue params to pam_limits hi, here's a patch that adds two parameters to pam_limits.c so you can set the limits on pending signals and POSIX queue memory. It applies against 0.77 (which is what my system is running) but looks like it should apply against 0.78 also.
Comment on attachment 108984 [details] adds sigpending and mqueue params to pam_limits one copy is enough
The patch looks OK, although you might need #ifdefs the new code. The problem is, though, that this is a change inthe configuration file format. I cannot speak for Tomas, but I wouldn't accept the patch unless it is blessed by upstream. Otherwise the upstream maintainer might use different keywords and then the config files are incompatible.
As I am one of the upstream maintainers, this shouldn't be a problem.
OK, I've commited that to upstream CVS however I've actually decided to rename the mqueue to msgqueue as all the other limits use the same name as in RLIMIT_xxxx defines. And I added the #ifdefs.
Created attachment 109462 [details] Patch applied to upstream
thanks Tomas!