getpwuid fails silently when run as root inside of mlockall()

[Dustin Kirkland ]

Use this test program

#include <pwd.h>
#include <stdio.h>
#include <errno.h>
#include <sys/mman.h>
int main() {
    struct passwd *pw = NULL;
    uid_t id;
    if (mlockall(MCL_FUTURE)<0) {
        perror("mlockall");
        return 1;
    }
    id = getuid();
    pw = getpwuid(id);
    if (pw == NULL) {
        perror("getpwuid");
        return errno;
    }
    printf("[%s]\n", pw->pw_name);
    return 0;
}

Build on Intrepid, and on Jaunty.

Run as root and non-root.

root@jaunty:
getpwuid: Success

kirkland@jaunty:
getpwuid: Resource temporarily unavailable

root@intrepid:
[root]

kirkland@intrepid:
getpwuid: Resource temporarily unavailable

Running this program as root on intrepid used to work. It does not in Jaunty. Additionally, errno is not set.

This regression is breaking mount.ecryptfs, which does a getpwuid() inside of just such an mlock.

:-Dustin

[Kees Cook (kees)]

(intrepid)root@gorgon:/tmp# ./bad
getpwuid: Success

Inside an intrepid chroot it fails as under jaunty. this implies some kind of kernel issue? raising mlock limits doesn't seem to affect it.

[Kees Cook (kees)]

Strangely... *lowering* the ulimit fixes it!

$ ulimit -l 32
$ sudo ./bad
[root]

[Kees Cook (kees)]

Er, no. Not any more. No idea what changed.

[Steve Beattie (sbeattie)]

This appears to be a recently introduced kernel bug; I get the root user returned correctly on 2.6.28-6.17, but I can reproduce the error on 2.6.28-7.20.

[Kees Cook (kees)]

smb found:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=0e42bda2d00f39a6b44b7feae376785fff2affad

[Tim Gardner (timg-tpi)]

This out to be fixed in 2.6.28-8.21: 'mm: fix error case in mlock downgrade reversion'

[Dustin Kirkland  (kirkland)]

Appears to me this was a kernel bug. Invalidating the glibc task. Feel free to add back, if I'm misreading the thread, though.

[Dustin Kirkland  (kirkland)]

To work around this issue, I added a little hack into eCryptfs to do the mlockall() slightly later (just after the getpwent call). This should be safe to revert now. Assigning to Wesley.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ecryptfs-utils - 99-0ubuntu1

---------------
ecryptfs-utils (99-0ubuntu1) quantal; urgency=low

  [ Dustin Kirkland ]
  * debian/ecryptfs-utils.postinst: LP: #936093
    - ensure desktop file is executable
  * precise

  [ Wesley Wiedenmeier ]
  * src/utils/mount.ecryptfs.c: LP: #329264
    - remove old hack, that worked around a temporary kernel regression;
      ensure that all mount memory is mlocked

  [ Sebastian Krahmer ]
  * src/pam_ecryptfs/pam_ecryptfs.c: LP: #732614
    - drop group privileges in the same places that user privileges are
      dropped
    - check return status of setresuid() calls and return if they fail
    - drop privileges before checking for the existence of
      ~/.ecryptfs/auto-mount to prevent possible file existence leakage
      by a symlink to a path that typically would not be searchable by
      the user
    - drop privileges before reading salt from the rc file to prevent the
      leakage of root's salt and, more importantly, using the incorrect salt
    - discovered, independently, by Vasiliy Kulikov and Sebastian Krahmer
  * src/pam_ecryptfs/pam_ecryptfs.c: LP: #1020904
    - after dropping privileges, clear the environment before executing the
      private eCryptfs mount helper
    - discovered by Sebastian Krahmer
  * src/utils/mount.ecryptfs_private.c: LP: #1020904
    - do not allow private eCryptfs mount aliases to contain ".." characters
      as a preventative measure against a crafted file path being used as an
      alias
    - force the MS_NOSUID mount flag to protect against user controlled lower
      filesystems, such as an auto mounted USB drive, that may contain a
      setuid-root binary
      + CVE-2012-3409
    - force the MS_NODEV mount flag
    - after dropping privileges, clear the environment before executing umount
    - discovered by Sebastian Krahmer

  [ Tyler Hicks ]
  * src/libecryptfs/key_management.c: LP: #732614
    - zero statically declared buffers to prevent the leakage of stack
      contents in the case of a short file read
    - discovered by Vasiliy Kulikov
  * src/libecryptfs/module_mgr.c, src/pam_ecryptfs/pam_ecryptfs.c:
    - fix compiler warnings
 -- Dustin Kirkland <email address hidden> Fri, 13 Jul 2012 09:52:36 -0500