I am able to reproduce this issue. I rebuild libpam-devperm with
debug symbols and ran 'valgrind atd -d' to get more details on the
crash, and this is the report:
==21819== Jump to the invalid address stated on the next line
==21819== at 0x0: ???
==21819== by 0x403339A: pam_sm_open_session (pam_devperm.c:137)
==21819== by 0x4042267: (within /lib/libpam.so.0.81.6)
==21819== by 0x40457EA: pam_open_session (in /lib/libpam.so.0.81.6)
==21819== by 0x80499F7: (within /usr/sbin/atd)
==21819== by 0x804A3D7: (within /usr/sbin/atd)
==21819== by 0x804A755: (within /usr/sbin/atd)
==21819== by 0x406044F: (below main) (in /lib/i686/cmov/libc-2.7.so)
==21819== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==21819==
==21819== Process terminating with default action of signal 11 (SIGSEGV)
==21819== Bad permissions for mapped region at address 0x0
==21819== at 0x0: ???
==21819== by 0x403339A: pam_sm_open_session (pam_devperm.c:137)
==21819== by 0x4042267: (within /lib/libpam.so.0.81.6)
==21819== by 0x40457EA: pam_open_session (in /lib/libpam.so.0.81.6)
==21819== by 0x80499F7: (within /usr/sbin/atd)
==21819== by 0x804A3D7: (within /usr/sbin/atd)
==21819== by 0x804A755: (within /usr/sbin/atd)
==21819== by 0x406044F: (below main) (in /lib/i686/cmov/libc-2.7.so)
Line 137 is the call to __write_message() here:
retval = pam_get_item (pamh, PAM_TTY, (const void **)&tty);
if (retval != PAM_SUCCESS || tty == NULL)
{
__write_message (pamh, flags, PAM_ERROR_MSG,
"cannot determine user's tty");
return PAM_SERVICE_ERR;
}
The back trace look like the function "pointer" __write_message is
NULL, and thus a call to the function fail. But as far as I can see,
it isn't a function pointer but a real function. Perhaps the dynamic
linker is confused?
Commenting out the __write_message() call got rid of the crash, but
now I got "Error in service module" printed and the at job was still
not executed. Looking at the code, it is not obvious to me how to fix
this. It is not clear to me what the module should do when there is
no tty available, as it is when at jobs are executed. Perhaps talk to
the upstream developer about this?
So, I see two problems here
- The pam module fail when there is no tty, and thus listing it as
required in /etc/pam.d/common-session will fail with the current
implementation.
- The pam module crashes when trying to write messages. No idea why.
I hope this can help someone along to find a fix for this issue.
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
