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

Status changed to 'Confirmed' because the bug affects multiple users.

Hy!

Commenting out "session optional pam_mount.so" from /etc/pam.d/common-session-noninteractive
I don't understand why it's included there in the first place? Can anyone explain? I can't found a reason in the changelog :(
Also if that's the real reason, the bug should reassigned to libpam-runtime.

I've just solved this bug. To solve it, someone has to login in with root account with 'sudo bash' in a terminal emulator, and open /etc/pam.d/common-session-noninteractive with 'gedit /etc/pam.d/common-session-noninteractive', and he or she has to look for the line n°16 and he or she has to change [default=1] in [default=0]. Try 'sudo id' or another command with 'sudo' and there is no bug!

I've just changed the status from "Comfirmed" to "Fix Released".

Not fixed in precise. I am getting this on a fresh upgrade to precise from oneiric.

example
sudo cat /etc/issue
Ubuntu precise (development branch) \n \l

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

The first command that I run with sudo from a terminal when it asks for the passord does not give me this error but if i run sudo after that when it does not ask for a password it will give me
sudo: pam_mount.c:417: modify_pm_count: Assertion `user != ((void *)0)' failed.
Aborted
at the end.

libpam-mount 2.10-2build1

Reset to confirmed. Please don't set to fix-released because of a workaround/fix - it needs the package to be fixed to be set to fix-released

Running sudo the first time, pam_mount tries to unmount my home dir ...

pam_mount(mount.c:69): umount messages:
pam_mount(mount.c:73): umount: ~: not found
pam_mount(mount.c:752): unmount of /dev/disk/by-uuid/bb50645a-08c7-4c85-98b7-af0f8c9de98b failed

(my home dir is mounted via pam_mount on login)

after that i get

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

I also experience this running 12.04 beta2.

pam_mount tries to unmount all of my encrypted volumes listed in pam_mount.conf.xml after I run sudo. After that, I get:

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

This appears to be caused by pam_mount.c::pam_sm_close_session().

When there are no volume list items the code 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)

----
$ sudo sed -i 's/\(pam_mount.so\)/\1 debug/' /etc/pam.d/common-session-noninteractive

$ sudo LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0 gdb -x /home/tj/gdb-sudo.cmd --args sudo echo TEST
sudo: /etc/sudoers.d/timestamp is mode 0644, but should be 0440
pam_mount(pam_mount.c:553): pam_mount 2.10: entering session stage
pam_mount(misc.c:38): Session open: (ruid/rgid=1000/1000, e=0/1000)
pam_mount(pam_mount.c:614): no volumes to mount
command: 'pmvarrun' '-u' 'root' '-o' '1'
pam_mount(misc.c:38): set_myuid<pre>: (ruid/rgid=1000/1000, e=0/1000)
pam_mount(misc.c:38): set_myuid<post>: (ruid/rgid=0/1000, e=0/1000)
pmvarrun(pmvarrun.c:252): parsed count value 98
pam_mount(pam_mount.c:440): pmvarrun says login count is 99
pam_mount(pam_mount.c:645): done opening session (ret=0)

GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /usr/bin/sudo...Reading symbols from /usr/lib/debug/usr/bin/sudo...done.
done.
Function "pam_begin_session" not defined.
Breakpoint 1 (pam_begin_session) pending.
Function "pam_end_session" not defined.
Breakpoint 2 (pam_end_session) pending.
Function "pam_sm_close_session" not defined.
Breakpoint 3 (pam_sm_close_session) pending.
Function "modify_pm_count" not defined.
Breakpoint 4 (modify_pm_count) pending.
(gdb) run
Starting program: /usr/bin/sudo echo TEST
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
sudo: /etc/sudoers.d/timestamp is mode 0644, but should be 0440
pam_mount(pam_mount.c:553): pam_mount 2.10: entering session stage
pam_mount(misc.c:38): Session open: (ruid/rgid=0/0, e=0/0)
pam_mount(pam_mount.c:614): no volumes to mount
command: 'pmvarrun' '-u' 'root' '-o' '1'
pam_mount(misc.c:38): set_myuid<pre>: (ruid/rgid=0/0, e=0/0)
pam_mount(misc.c:38): set_myuid<post>: (ruid/rgid=0/0, e=0/0)
pmvarrun(pmvarrun.c:252): parsed count value 99
pam_mount(pam_mount.c:440): pmvarrun says login count is 100
pam_mount(pam_mount.c:645): done opening session (ret=0)
TEST

Breakpoint 2, pam_end_session (pw=0x20fa938, auth=0x7fc7cbf4a620) at /build/buildd/sudo-1.8.3p1/plugins/sudoers/auth/pam.c:243
243 {
(gdb) n
246 if (pamh != NULL) {
(gdb) n
252 (void) pam_set_item(pamh, PAM_USER, pw->pw_name);
(gdb) n
253 (void) pam_close_session(pam...

Upstream bug tracker: https://sourceforge.net/tracker/?func=detail&aid=3519691&group_id=41452&atid=430593

The crux of the problem is that sudo in Precise (v1.8.3p1) is a massively re-factored code-base compared to v1.7.4p6 in Oneiric.

From what I've been able to deduce sudo has been massively re-written to use a 'plugin' architecture to easily support many different authorisation mechanisms. This seems to have divorced the sudo timestamp checking from the PAM authentication logic such that if a valid sudo timestamp exists for the user then a PAM session (via pam_open_session() ) is never created.

The sudo session closing logic however doesn't know this and blindly goes on to try and close the PAM session (via pam_close_session() ) which discovers that the PAM Config hasn't been initialised during authentication and hits this assert.

Next I'm going to look at the current upstream sudo in detail to see if this issue has been resolved and whether it is possible to backport any change.

I've tracked the call paths in Precise's v1.8.3p1 and provide it here.

plugins/sudoers/sudoers.c::sudoers_policy_main()
    /* Require a password if sudoers says so. */
    rval = check_user(validated, sudo_mode);
    if (rval != TRUE)
 goto done;

plugins/sudoers/check.c::check_user()
    status = timestamp_status(timestampdir, timestampfile, user_name,
 TS_MAKE_DIRS);

////**** TJ: if the timestamp is valid status == TS_CURRENT
////**** this code never calls verify_user() so the PAM session is not created.

    if (status != TS_CURRENT || ISSET(validated, FLAG_CHECK_USER)) {
    ...
     rval = verify_user(auth_pw, prompt);

plugins/sudoers/auth/sudo_auth.c::verify_user()

    while (--counter) {
    ...
 /* Call authentication functions. */
 for (auth = auth_switch; auth->name; auth++) {
     if (IS_DISABLED(auth))
  continue;

     if (NEEDS_USER(auth))
  set_perms(PERM_USER);

     success = auth->status = (auth->verify)(pw, p, auth);

plugins/sudoers/auth/sudo_auth.h
typedef struct sudo_auth {
    int flags; /* various flags, see below */
    int status; /* status from verify routine */
    char *name; /* name of the method as a string */
    void *data; /* method-specific data pointer */
    int (*init)(struct passwd *pw, struct sudo_auth *auth);
    int (*setup)(struct passwd *pw, char **prompt, struct sudo_auth *auth);
    int (*verify)(struct passwd *pw, char *p, struct sudo_auth *auth);
    int (*cleanup)(struct passwd *pw, struct sudo_auth *auth);
    int (*begin_session)(struct passwd *pw, struct sudo_auth *auth);
    int (*end_session)(struct passwd *pw, struct sudo_auth *auth);
} sudo_auth;

plugins/sudoers/auth/sudo_auth.c
static sudo_auth auth_switch[] = {
/* Standalone entries first */
#ifdef HAVE_PAM
    AUTH_ENTRY("pam", FLAG_STANDALONE, pam_init, NULL, pam_verify, pam_cleanup, pam_begin_session, pam_end_session)
#endif

plugins/sudoers/auth/pam.c::pam_verify()
    *pam_status = pam_authenticate(pamh, PAM_SILENT);

...

src/sudo.c::exec_setup()
    if (policy_init_session(&policy_plugin, pw) != TRUE)
 goto done;

src/sudo.c::policy_init_session()
{
    if (plugin->u.policy->init_session)
 return plugin->u.policy->init_session(pwd);

plugin/sudoers/sudoers.c::sudoers_policy_init_session()
    return sudo_auth_begin_session(pwd);

p...

Updated bug-tracker to upstream project

The proposed fix of changing [default=1] to [default=0] in '/etc/pam.d/common-session-noninteractive' causes problems with 'cron'.

Cron jobs are no longer executed. Syslog entry says 'CRON[process id]: Permission denied'.

Felix: that isn't a proposed fix - it is simply a work around that Francesco discovered, but it caused pam_denied to run so all authorisations fail.

I now have a patch that fixes the issue that works with the current upstream tip (1.8.5 release candidate), thanks to a swift response by its author Todd Miller.

I am investigating applying that fix to our 1.8.3p1 and if it is good I'll propose an SRU for Precise.

I've modified the upstream fix for 1.8.5-RC so it applies to 1.8.3p1. I've linked my bazaar branch that contains the fix:

sudo (1.8.3p1-1ubuntu4) precise; urgency=low

  * Fix Abort in some PAM modules when timestamp is valid. (LP: #927828)

 -- TJ (Ubuntu Contributions) <email address hidden> Sat, 21 Apr 2012 13:51:24 +0100

The package is now in my PPA and will be published for user testing shortly.

https://launchpad.net/~intuitivenipple/+archive/ppa?field.series_filter=precise

Since this bug only seems to affect systems with libpam-mount installed, and that isn't installed by default, we're trying to determine which package causes its installation.

Could those affected please report the result of:

apt-cache policy sadms

Status changed to 'Confirmed' because the bug affects multiple users.

For me, I installed libpam-mount explicitly long ago in order to auto mount encfs volumes on login. I don't have sadms installed, but here's the policy run anyway as requested by TJ:

$ apt-cache policy sadms
sadms:
  Installed: (none)
  Candidate: 2.0.15.repack-0ubuntu2
  Version table:
     2.0.15.repack-0ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise/universe amd64 Packages

Brett, thanks. The reason for the request was I was discussing the issue with Colin Watson on IRC and he pointed out the package isn't pulled in by default. So aside from explicit manual installations as in your case we wan't to figure out how it got installed - since it is the only PAM module we know of (so far) that exposes the underlying bug in sudo.

We can see a reverse-depends on libpam-mount from sadms and I wanted to confirm that is the way libpam-mount got onto systems without explicit installation.

apt-cache policy sadms
sadms:
  Installed: (none)
  Candidate: 2.0.15.repack-0ubuntu2
  Version table:
     2.0.15.repack-0ubuntu2 0
        500 http://archive.ubuntu.com/ubuntu/ precise/universe amd64 Packages

apt-cache policy sadms
sadms:
  Installed: (none)
  Candidate: 2.0.15.repack-0ubuntu2
  Version table:
     2.0.15.repack-0ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise/universe amd64 Packages

according to my package history
libpam-mount was installed on my system
Commit Log for Sat Apr 2 17:27:16 2011
Installed the following packages:
libpam-mount (2.8-1)

It was then upgraded on Commit Log for Tue Apr 3 19:58:02 2012.
It looks like I had an error with it because it says
Reinstalled the following packages:
libpam-mount (2.10-2build1)

And as far as package history shows sadms has never been installed.

sadms is not installed here; not an AD environment. Version table as for the users above.

sadms:
  Installed: (none)
  Candidate: 2.0.15.repack-0ubuntu2
  Version table:
     2.0.15.repack-0ubuntu2 0
        500 http://gb.archive.ubuntu.com/ubuntu/ precise/universe i386 Packages

Presents here on a upgraded freshly-installed beta2 VM using libnss-ldapd with nslcd for accounts, libpam-ldapd for auth, pam_mkhomedir for user home creation, pam_mount for network share mounts; explicit installations and custom libpam-runtime configs where necessary. This is surely a common enough scenario.

Please fix this problem ASAP.

I am using encrypted home using tools from this package

/sbin/umount.crypt
/sbin/mount.crypto_LUKS
/sbin/umount.crypto_LUKS
/sbin/mount.crypt_LUKS
/sbin/umount.crypt_LUKS

But sometime I have more severe outcome.
My Unity crashes and goes to loging screen wnen I run "sudo something"

- Dmitry

More.. It started to happen when I upgraded to 12.04...

apt-cache policy sadms
sadms:
  Installed: (none)
  Candidate: 2.0.15.repack-0ubuntu2
  Version table:
     2.0.15.repack-0ubuntu2 0
        500 http://ubuntu-archives.mirror.nexicom.net/ precise/universe amd64 Packages

Same results as others above.

Another workaround is to set the "timestamp_timeout" option in /etc/sudoers to 0.
This way, sudo always asks for the password which apparently avoids the error.

This bug was fixed in the package sudo - 1.8.3p1-1ubuntu4

---------------
sudo (1.8.3p1-1ubuntu4) quantal; urgency=low

  * Fix Abort in some PAM modules when timestamp is valid. (LP: #927828)
 -- TJ (Ubuntu Contributions) <email address hidden> Mon, 30 Apr 2012 17:55:27 +0100

Hello Sean, or anyone else affected,

Accepted into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Works :-).

Btw: the workaround in #4 kills samba user authentication too.

I can confirm that minimally installing patched sudo in precise-proposed, 1.8.3p1-1ubuntu3.1, onto an affected system otherwise cleanly upgraded from beta2 makes the assertion go away immediately after installation.

I installed the sudo from precise-proposed and the annoying pam_mount umount messages are gone when using sudo.

Fantastic...
'sudo id' does not crash might desktop anymore...

thanks.

If you don't want to enable the "proposed" repository, here's a quick way to install the fixed sudo:

sudo -i # <---- this helps work around the bug in the current version of sudo
wget -c -t 0 'https://launchpad.net/ubuntu/+source/sudo/1.8.3p1-1ubuntu3.1/+build/3453511/+files/sudo_1.8.3p1-1ubuntu3.1_amd64.deb'
dpkg -i sudo_1.8.3p1-1ubuntu3.1_amd64.deb

I have sudo 1.8.3p1-1ubuntu3.1 from precise-proposed and I use pam_mount for mounting encrypted partitions at login.

While the original bug is fixed with the 1ubuntu3.1 version of sudo, 'sudoedit' command triggers pam_mount to enquire the password of the encrypted partition, trying to mount it and later to umount it. Mounting and umounting fails, because the encrypted partition is already mounted, unlocked and busy.

$ sudoedit test
reenter password for pam_mount:
pam_mount(mount.c:69): Messages from underlying mount program:
pam_mount(mount.c:73): crypt_activate_by_passphrase: File exists
pam_mount(pam_mount.c:521): mount of /dev/myvolumehere/mypartitionhere failed
pam_mount(mount.c:69): umount messages:
pam_mount(mount.c:73): umount: /mnt/mymountedpartition: device is busy.
pam_mount(mount.c:73): (In some cases useful info about processes that use
pam_mount(mount.c:73): the device is found by lsof(8) or fuser(1))
pam_mount(mount.c:73): umount /mnt/mymountedpartition failed with run_sync status 1
pam_mount(mount.c:73): umount: /mnt/mymountedpartition: device is busy.
pam_mount(mount.c:73): (In some cases useful info about processes that use
pam_mount(mount.c:73): the device is found by lsof(8) or fuser(1))
pam_mount(mount.c:73): umount /mnt/mymountedpartition failed with run_sync status 1
pam_mount(mount.c:752): unmount of /dev/myvolumehere/mypartitionhere failed

sudo does not trigger this behavior, just sudoedit.

Jari, thank-you.Did sudoedit behave like this before the upgrade in -proposed? Please report this as a new bug against sudo and let me know the bug #. I'll investigate and pass it upstream if necessary.

That seems like a bug in pam_mount for not having sensible reference counting behavior for mounts used by multiple sessions, and not a bug in the sudo patch. How does this work if you try to log in twice over ssh to the same account?

Ah, but if this is only with sudoedit and not with sudo, something else may be wrong.

I donwgraded to version sudo=1.8.3p1-1ubuntu3:

shell:~$ sudoedit test
reenter password for pam_mount:
pam_mount(mount.c:69): Messages from underlying mount program:
pam_mount(mount.c:73): crypt_activate_by_passphrase: File exists
pam_mount(pam_mount.c:521): mount of /dev/myvolumehere/mypartitionhere failed
sudoedit: pam_mount.c:417: modify_pm_count: Assertion `user != ((void *)0)' failed.
Aborted
shell:~$ ls test
ls: cannot access test: No such file or directory

So also sudoedit was unusable with the old version. I'll open a new bug against sudo.

Steve,

two simultaneous ssh's to a server with already mounted encrypted partitions do not print errors for the user.
However, auth.log records the following lines:

May 8 23:11:17 myserver sshd[22228]: Accepted password for myuser from xxx.xxx.xxx.xxx port 36342 ssh2
May 8 23:11:17 myserver sshd[22228]: pam_unix(sshd:session): session opened for user myuser by (uid=0)
May 8 23:11:17 myserver sshd[22228]: pam_mount(mount.c:69): Messages from underlying mount program:
May 8 23:11:17 myserver sshd[22228]: pam_mount(mount.c:73): crypt_activate_by_passphrase: File exists
May 8 23:11:17 myserver sshd[22228]: pam_mount(pam_mount.c:521): mount of /dev/myvolumehere/mypartitionhere failed
May 8 23:11:33 myserver sshd[22472]: Accepted password for myuser from xxx.xxx.xxx.xxx port 36343 ssh2
May 8 23:11:33 myserver sshd[22472]: pam_unix(sshd:session): session opened for user myuser by (uid=0)
May 8 23:11:33 myserver sshd[22472]: pam_mount(mount.c:69): Messages from underlying mount program:
May 8 23:11:33 myserver sshd[22472]: pam_mount(mount.c:73): crypt_activate_by_passphrase: File exists
May 8 23:11:33 myserver sshd[22472]: pam_mount(pam_mount.c:521): mount of /dev/myvolumehere/mypartitionhere failed

I filed a bug #996806 against sudo in ubuntu for the sudoedit and pam_mount bug. Thanks!

This bug was fixed in the package sudo - 1.8.3p1-1ubuntu3.1

---------------
sudo (1.8.3p1-1ubuntu3.1) precise-proposed; urgency=low

  * Fix Abort in some PAM modules when timestamp is valid. (LP: #927828)
 -- TJ (Ubuntu Contributions) <email address hidden> Mon, 30 Apr 2012 18:05:21 +0100

Well, excuse me for the last post that I wrote, but for me the problem was solved... Another time I'll don't do that. But now I have another problem, with uswsusp and the log says that: "Sessions still open, not unmounting pam_mount(spawn.c:128): error setting uid to 0 Sessions still open, not unmounting" and it's the only error in th log. And with the upgrade of the package on precie-proposed '/etc/pam.d/common-session-noninteractive', the [default=] is [default=0] and I haven't problem with the login or 'sudo id'. I tried to use tuxonice but nothing. The pc doesn't hibernate. So I if someone can help me, I'll be happy. Thanks and excuse for the last post. P.S. When on 02/06 I changed [default=0] to [default=1], I haven't any problems reported from the olther users. Is possible that? And thanks for the answers.

And sorry, but I have to chage the state of the bug.

I've just reported the bug in uswsusp package: https://bugs.launchpad.net/ubuntu/+source/uswsusp/+bug/999935