This is the patch that I came up with to fix pam_limits.c
The repair was to add 2 lines to top of the parse_uid_range function:
if (range[0]== '*' )
return LIMIT_RANGE_NONE;
and to fix the Use/Case for limits set for the root user in parse_config_file:
if ( uid==0) { //don't process root limits unless specified in the config file
break; // fall
out of switch/case because we are root
** Patch added: "Add to parser system the fix"
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1691847/+attachment/4879196/+files/pam_limits.patch
** Description changed:
- Steve
-
- We at Sandia Labs are trying to use Ubuntu 16.04 LTS for our HPC
- systems. I’ve identified a bug that prevents ‘* - memlock unlimited’
- from being implemented in /etc/security/limits.conf
-
- Here is my patch that, I believe, fixes the issue.
-
- Mike Aguilar
- [email protected]
-
- cat pam_limits.patch
- --- pam_limits.c.ori 2017-05-16 09:44:02.819262851 -0600
- +++ pam_limits.c 2017-05-16 09:44:48.131237292 -0600
- @@ -691,6 +691,9 @@
- return LIMIT_RANGE_NONE;
- ++pmax;
-
- + if (range[0]=='*')
- + return LIMIT_RANGE_NONE;
- +
- if (range[0] == '@' || range[0] == '%')
- ++range;
-
- @@ -854,9 +857,14 @@
- } else {
- switch(rngtype) {
- case LIMIT_RANGE_NONE:
- - if (strcmp(domain, "*") == 0)
- + if (strcmp(domain,"*")==0) {
// process for everyone, except for root (next line)
- + if ( uid==0) { //don't
process root limits unless specified in the config file
- + break; // fall
out of switch/case because we are root
- + } else { // we aren't
root, so let's go ahead and set the limits
- process_limit(pamh,
LIMITS_DEF_DEFAULT, ltype, item, value, ctrl,
-
pl);
- + }
- + }
- break;
- case LIMIT_RANGE_ONE:
- if (uid != max_uid)
+ I identified a bug in the pam_limits.c source code for Ubuntu 16.04LTS, as
follows:
+
+ It appears that I managed to modify/"fix" the '*' unlimited memlock error in
pam_limits.c.
+
+ I modified the code on a VM and it appears on a VM to allow us to get the
memlock hard and soft to work. That should be what we need to get SLURM
working, if inserting the new compiled pam_limits.so code into the image works
straight away. After compiling and running the modified code with the
/etc/security/limits.conf line of '* - memlock unlimited', I am getting
my user limits setting as 'ulimit -l unlimited'.
+
+ After studying the code more carefully, I found that the C function, parse
_config_file was first gathering the domain entry for the user/group/everyone
in an sscanf function. Using the domain result, a second function was called
from within a loop, parse_uid_range. A range_type value, an integer reflecting
the set range of users was to be returned to the parse_config_file function.
However, in the case of '*' (Kleene star), no range_type was ever returned.
Further down in parse_config_file, the range_type was checked for a
LIMIT_RANGE_NONE value and '*' (the Kleene star). Because range_type did not
hold the LIMIT_RANGE_NONE value, the process_limit function call was never made
for '*' and instead a line break occurred that by-passed the execution of
putting in universal limits.
** Description changed:
- I identified a bug in the pam_limits.c source code for Ubuntu 16.04LTS, as
follows:
-
- It appears that I managed to modify/"fix" the '*' unlimited memlock error in
pam_limits.c.
-
- I modified the code on a VM and it appears on a VM to allow us to get the
memlock hard and soft to work. That should be what we need to get SLURM
working, if inserting the new compiled pam_limits.so code into the image works
straight away. After compiling and running the modified code with the
/etc/security/limits.conf line of '* - memlock unlimited', I am getting
my user limits setting as 'ulimit -l unlimited'.
-
- After studying the code more carefully, I found that the C function, parse
_config_file was first gathering the domain entry for the user/group/everyone
in an sscanf function. Using the domain result, a second function was called
from within a loop, parse_uid_range. A range_type value, an integer reflecting
the set range of users was to be returned to the parse_config_file function.
However, in the case of '*' (Kleene star), no range_type was ever returned.
Further down in parse_config_file, the range_type was checked for a
LIMIT_RANGE_NONE value and '*' (the Kleene star). Because range_type did not
hold the LIMIT_RANGE_NONE value, the process_limit function call was never made
for '*' and instead a line break occurred that by-passed the execution of
putting in universal limits.
+ I identified a bug in the pam_limits.c source code for Ubuntu 16.04LTS,
+ as follows:
+
+ It appears that I managed to modify/"fix" the '*' unlimited memlock
+ error in pam_limits.c.
+
+ After compiling and running the modified code with the
+ /etc/security/limits.conf line of '* - memlock unlimited', I am
+ getting my user limits setting as 'ulimit -l unlimited'.
+
+ After studying the code more carefully, I found that the C function,
+ parse _config_file was first gathering the domain entry for the
+ user/group/everyone in an sscanf function. Using the domain result, a
+ second function was called from within a loop, parse_uid_range. A
+ range_type value, an integer reflecting the set range of users was to be
+ returned to the parse_config_file function. However, in the case of '*'
+ (Kleene star), no range_type was ever returned. Further down in
+ parse_config_file, the range_type was checked for a LIMIT_RANGE_NONE
+ value and '*' (the Kleene star). Because range_type did not hold the
+ LIMIT_RANGE_NONE value, the process_limit function call was never made
+ for '*' and instead a line break occurred that by-passed the execution
+ of putting in universal limits.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1691847
Title:
* <type> <limit> <value> broken
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1691847/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
