#103 modify_pm_count: Assertion `user != ((void *)0)' failed.

[Anonymous]

pam_mount.c:417: modify_pm_count: Assertion `user != ((void *)0)' failed.

This occurs frequently with sudo when it caches authentication credentials *and* no mount volumes are defined for the user. Bug #3428236 was closed as invalid with the blame pointed at sudo, but my analysis indicates it is a NULL pointer dereference in pam_mount.c::modify_pm_count() caused by an unexpected code-path in pam_mount.c::pam_sm_close_session() taking an early exit before ensuring Config.user is set.

I don't fully understand the interaction with sudo but I believe that without authenication-caching it calls pam_sm_authenticate(), pam_sm_open_session() and pam_sm_close_session(). The latter inherits a fully populated struct Config.

In the sudo-caching case I believe pam_sm_authenticate() may not be called. During debugging I do not see calls to pam_open_session() either.

When there are no volume list items the code in pam_sm_close_session() that explicitly gets the user name is skipped over:

if (Config.volume_list.items == 0) {
w4rn("No volumes to umount\n");
goto out;
}

which results in Config.user not being set (its default value is NULL) which causes the assert() in modify_pm_count.

out:
envpath_init(Config.path);
if (modify_pm_count(&Config, Config.user, "-1") > 0)

[Anonymous]

gdb debug trace on Ubuntu 12.04 (libpam_mount 2.10)

[Anonymous]

Follow-up. Here's struct Config in pam_sm_close_session()

(gdb) p Config
$1 = {user = 0x0, debug = 0, mkmntpoint = false, rmdir_mntpt = false, seen_mntoptions_require = false,
seen_mntoptions_allow = false, luserconf = 0x0, command = {0x0 <repeats 17 times>}, options_require = 0x0, options_allow = 0x0,
options_deny = 0x0, volume_list = {{list = {next = 0x0, prev = 0x0}, {next = 0x0, prev = 0x0}}, items = 0}, level = 0,
msg_authpw = 0x0, msg_sessionpw = 0x0, path = 0x0, sig_hup = false, sig_term = false, sig_kill = false, sig_wait = 0}

[Jan Engelhardt]

The reason the assert triggers, because the sudo code arranges for pam_close_session() [function in libpam] to be called _even though_ pam_open_session() has not been called by sudo.

The PAM Application Developer Guide mentions: "The pam_close_session function is used to indicate that an authenticated session has ended. The session should have been created with a call to pam_open_session(3)." While "should" marks an optional requirement, the ADG never said anywhere that it is using the RFC definitions of "SHOULD".

Given that all other programs (su, login, the xdms, even sshd) do proper paired calls to open and close, I think that sudo is in error (and that in more than one way if I shall interpret the non-pam_mount-involving involving crash report bug list in bugs.debian.org/sudo )

More technical details in bugs.debian.org/648066 .

[Anonymous]

On Ubuntu at least, whilst researching this I discovered the same issue affected lightdm. Unfortunately it 'went away' due to some unknown changes to the PAM packages so that doesn't help compare/contrast with sudo.

Is the lifetime of a PAM session just the time the process exists? I ask because I'm wondering if the sudo code is considering the session to last from the first invocation of sudo that gives the password prompt and doesn't end untl the sudo timestamp delay (default 5 mins) expires.

I'm trying to understand PAM well enough to suggest the "correct" fix - where-ever that should be.