Re: pam application doesn't release sockets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


28.01.2011 00:42, Thorsten Kukuk wrote:

So I have another question:
How to properly configure pam authentication for a program in the same way
as in a system? Regardless of whether it is pam_ldap or pam_unix.
? I don't understand your question. The configuration should always
be the same and depends on your needs.

Some systems are configured to authenticate users against /etc/shadow passwords, some of them authenticate against Ldap, Kerberos etc. As far as I understand, this functionality described in /etc/pam.d/system-auth in fedora/rhel or /etc/pam.d/common-[account,auth,password,session] in debian/ubuntu.

I want my program to authenticate the same way as in this config even if it will be changed.

I'm not very experienced in linux programming, so I'll try to do this later.
Another challenge I'll try to solve is find the cause of memory leak
(valgrind --leak-check=full):
34 bytes doesn't look like a memory leak, more like some data
glibc allocates internal when dlopen is called the first time.

It is a leak. In a long running program it will be more than 34 bytes:

==469==     in use at exit: 680 bytes in 40 blocks
==469== total heap usage: 402,469 allocs, 402,429 frees, 147,048,522 bytes allocated
==469== 680 bytes in 40 blocks are definitely lost in loss record 1 of 1
==469==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==469==    by 0xA8107E: local_strdup (in /lib/
==469==    by 0xA842CB: _dl_map_object (in /lib/
==469==    by 0xA8EE5D: dl_open_worker (in /lib/
==469==    by 0xA8A975: _dl_catch_error (in /lib/
==469==    by 0xA8E945: _dl_open (in /lib/
==469==    by 0xC57C3A: dlopen_doit (in /lib/
==469==    by 0xA8A975: _dl_catch_error (in /lib/
==469==    by 0xC5803B: _dlerror_run (in /lib/
==469==    by 0xC57B70: dlopen@@GLIBC_2.1 (in /lib/
==469==    by 0x712143C: ??? (in /lib/
==469==    by 0x712255F: NSSLOW_Init (in /lib/
==469==    definitely lost: 680 bytes in 40 blocks
==469==    indirectly lost: 0 bytes in 0 blocks
==469==      possibly lost: 0 bytes in 0 blocks
==469==    still reachable: 0 bytes in 0 blocks
==469==         suppressed: 0 bytes in 0 blocks
==469== For counts of detected and suppressed errors, rerun with: -v
==469== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 339 from 13)

Best regards, Evgeny Tarasov

Pam-list mailing list

[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux