[Dovecot] auth-worker always opens PAM session
I'm using Dovecot 1.1.7 on CentOS 5.2.
I've changed my passdb from passwd to pam, it works fine, but I've found this messages on /var/log/secure:
dovecot-auth: PAM adding faulty module: /lib64/security/pam_limits.so dovecot-auth: PAM unable to dlopen(/lib64/security/pam_limits.so) dovecot-auth: PAM [error: /lib64/security/pam_limits.so: failed to map segment from shared object: Cannot allocate memory]
Latter I realized that my auth_process_size was 64. Changed it to 128 and problem solved.
But I suspect that dovecot should not be opening sessions, because there is no session=yes on my passdb configuration.
According to the docs:
args = dovecot
[session=yes] [setcred=yes] [failure_show_msg=yes] [cache_key=<key>] [<service name>]
session=yes makes Dovecot open and immediately close PAM session. Some PAM plugins need this to work, such as pam_mkhomedir.
I checked the source code in passdb-pam.c:
struct pam_passdb_module { struct passdb_module module;
const char *service_name, *pam_cache_key;
unsigned int pam_setcred:1;
unsigned int pam_session:1;
unsigned int failure_show_msg:1;};
And this:
/* -session for backwards compatibility */ if (strcmp(t_args[i], "-session") == 0 || strcmp(t_args[i], "session=yes") == 0) module->pam_session = TRUE;
It seams to me that the session is going to be opened anyway, since pam_session is always TRUE.
Regards,
Miguel
On Thu, 2009-02-19 at 13:59 -0300, Miguel Di Ciurcio Filho wrote:
But I suspect that dovecot should not be opening sessions, because there is no session=yes on my passdb configuration.
Why do you think it is opening sessions?
/* -session for backwards compatibility */ if (strcmp(t_args[i], "-session") == 0 || strcmp(t_args[i], "session=yes") == 0) module->pam_session = TRUE;
It seams to me that the session is going to be opened anyway, since pam_session is always TRUE.
Why? That code sets it to TRUE only when -session or session=yes parameter is seen.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Timo Sirainen wrote:
Why do you think it is opening sessions?
Dovecot giving this memory errors about being unable to load pam_limits.so seamed strange to me.
dovecot-auth: PAM adding faulty module: /lib64/security/pam_limits.so dovecot-auth: PAM unable to dlopen(/lib64/security/pam_limits.so) dovecot-auth: PAM [error: /lib64/security/pam_limits.so: failed to map segment from shared object: Cannot allocate memory]
Because pam_limits is configured to be loaded only on sessions in pam's configuration on my CentOS server.
Sorry for my ignorance, but isn't this code setting pam_session TRUE by default? Just a hunch, since it is being set to 1.
struct pam_passdb_module { struct passdb_module module;
const char *service_name, *pam_cache_key;
unsigned int pam_setcred:1;
unsigned int pam_session:1;
unsigned int failure_show_msg:1;};
/* -session for backwards compatibility */ if (strcmp(t_args[i], "-session") == 0 || strcmp(t_args[i], "session=yes") == 0) module->pam_session = TRUE;
Why? That code sets it to TRUE only when -session or session=yes parameter is seen.
I know, but as I said earlier it looks to me that module->pam_session is already TRUE even if there is no session=yes.
Sorry to bother if I'm reading the source code wrong.
Regards,
Miguel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmgXuQACgkQA18OC149llIfCACfdlNKe0bGtnNEqfBKbSRqaq4P hEcAn1HUCN4O45l/SJ8NEyb3Gt1qg68S =ErwH -----END PGP SIGNATURE-----
On Sat, 2009-02-21 at 17:07 -0300, Miguel Di Ciurcio Filho wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Timo Sirainen wrote:
Why do you think it is opening sessions?
Dovecot giving this memory errors about being unable to load pam_limits.so seamed strange to me.
I think PAM simply loads all modules, whether it actually uses them or not. Or if not all, then if the limits is listed somewhere it loads it before knowing if the session is going to be opened or not.
Sorry for my ignorance, but isn't this code setting pam_session TRUE by default? Just a hunch, since it is being set to 1. .. unsigned int pam_session:1;
You mean this code? No, that just means it uses 1 bit of memory.
participants (2)
-
Miguel Di Ciurcio Filho
-
Timo Sirainen