Public bug reported:
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.
** Affects: pam (Ubuntu)
Importance: Undecided
Status: New
** 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
-
+
+ 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
+
+ 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;
+ ++pmax;
+
+ + if (range[0]=='*')
+ return LIMIT_RANGE_NONE;
+
- if (range[0] == '@' || range[0] == '%')
- ++range;
-
+ if (range[0] == '@' || range[0] == '%')
+ ++range;
+
@@ -854,9 +857,14 @@
- } else {
- switch(rngtype) {
- case LIMIT_RANGE_NONE:
+ } 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);
+ process_limit(pamh,
LIMITS_DEF_DEFAULT, ltype, item, value, ctrl,
+
pl);
+ }
+ }
- break;
- case LIMIT_RANGE_ONE:
- if (uid != max_uid)
-
-
-
- Our Use/Case is below, in case you need it:
-
- Here is our Use-Case and a description of the issue:
-
-
- Use-Case ID:
- HSA Cluster
- Actors:
- ROCM, SLURM, HSA cluster/Kokkos developer
- Description:
- Using SLURM and OpenMPI, distribute and gather and reduce HSA computations
using Infiniband
- Preconditions:
- AMD ROCM installed and running, Mellanox OFED installed and running, SLURM
(LLNL version) installed and running, OpenMPI compiled using ROCM compilers,
Unlimited memory set using Pam_Limits module
- Normal Flow:
- Kokkos developer logs into head node
- Kokkos developer writes HSA code and MPI code
- Kokkos developer compiles HSA code using MPI compiler over HSA ROCM compiler.
- Kokkos code is submitted using SLURM
- Alternate Flow
- Kokkos developer logs into head node
- Kokkos developer writes HSA code and MPI code
- Kokkos developer compiles HSA code using MPI compiler over HSA ROCM compiler.
- Kokkos code is submitted using SLURM
- Kokkos code fails due to Pam_Limits module failure on Ubuntu OS
+ break;
+ case LIMIT_RANGE_ONE:
+ if (uid != max_uid)
--
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
