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
- mjag...@sandia.gov
- 
- 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
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/1691847

Title:
  * <type> <limit> <value> broken

Status in pam package in Ubuntu:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1691847/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to