Bug 173525

Created attachment 121207 [details]
PAM test program - cimservera.cpp

Created attachment 121208 [details]
PAM test program - cimservera.h

Created attachment 121209 [details]
/etc/pam.d/wbem - PAM configuration file for test

The memory growth is more pronounced on x86_64 running in 64-bit mode.

Please report the bug using the issue tracker. This way it can get proper
attention for fixing in RHEL 4. Also mention this bug report number in the issue
tracker entry. Thank you.

Created attachment 124437 [details]
valdrind output

I've tried to reproduce it and I couldn't find any memory leaks neither with
valgrind nor with mtrace().

I've actually already traced for memory leaks in a year ago and there were some
mem-leaks in pam_stack.so but that was it.

So I don't think there are any memory leaks in PAM currently - at least not in
the modules specified in the wbem config file.

Thanks for the debugging. I've finally found out what is the culprit. The
problem lies in the selinux library which contains constructor functions
init_selinuxmnt and init_selinux_policyroot which allocate various data and
there are no appropriate destructors.

Do we need this fixed, since this only happens when you load the library?  It is
fixed in the upstream version.

This would only leak memory if you were repeatedly doing dlopen and closes on
libselinux.

This is exactly what happens when you call PAM repeatedly in one process. So I'd
say this selinux library defect should be fixed.

Which process is growing out of control?

BTW  1.19.1-7.1 has a fix for this.  But I still do not know if this is worth
updating.

Yes, please can we get a fix for this issue in RHEL-4-U4 - it is causing all
users of the tog-pegasus package a major headache, as the tog-pegausus cimserver
performs PAM authentication for every request, and experiences around 1K memory
growth per request, all due to libselinux memory leaks.
I'm attaching the test program, the valgrind output, and the patch that fixes
the major libselinux memory leak.

Created attachment 127808 [details]
test program exhibiting memory growth in libselinux

Usage:
# gcc -g -o pam_mem pam_mem.c -lpam -lselinux
# valgrind --tool=memcheck --leak-check=yes --show-reachable=yes
--leak-resolution=high --num-callers=40 ./pam_mem pegasus pegasus
(assuming you have a "pegasus" user with password "pegasus")

Created attachment 127809 [details]
valgrind log from 1 iteration for 1 successful authentication

Created attachment 127810 [details]
patch to libselinux-1.19.1-7.1 that fixes memory leak in selinux_config.c

Created attachment 127811 [details]
valgrind log from same pam_mem run after libselinux patch applied, showing no memory leak

Please can we try to get a fix into RHEL-4-U4 for this issue - it is causing
IBM and HP pegasus users major problems, and is the #1 issue they would like
us to fix for pegasus in RHEL-4.

Unfortunately, the updated libselinux-1.19.1-7.1 package submitted for errata 
RHBA-2006:0371-03 still contains the most significant memory leak - it fixes
only the leak of the "selinux_mnt" memory, not the leak of the 
selinux_policyroot memory nor that of the file_paths[i] .  

Please see the patch which fixes those leaks which I attached to this bug
earlier :
  Attachment 127810 [details] https://bugzilla.redhat.com/bugzilla//attachment.cgi?id=127810

The updated libselinux-1.19.1-7.1 packages attached to errata RHBA-2006:0371-03 
generated the memory leaks shown in the 'pam_mem_valgrind-1.19-7.1.log' 
I'm just about to attach .

Created attachment 128371 [details]
valgrind log file showing memory leaks still present with libselinux-1.19-7.1

added patch libselinux-1_19_1-7_2

Terrific! Thanks alot, Dan - all tests pass now - no memory leaks observed.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0371.html