unable to show the contents of my kernel keyring

Found a work around for now.

While 'keyctl show' does not work, 'keyctl list @u' does. Use that for now.

:-Dustin

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

---------------
ecryptfs-utils (76-0ubuntu1) karmic; urgency=low

  [ Dustin Kirkland ]
  * src/utils/ecryptfs-setup-swap: switch from vol_id to blkid,
    LP: #376486
  * debian/ecryptfs-utils.postinst, src/utils/ecryptfs-setup-private:
    don't echo mount passphrase if running in bootstrap mode; prune
    potential leakages from install log, LP: #383650
  * SECURITY UPDATE: mount passphrase recorded in install log (LP: #383650).
    - debian/ecryptfs-utils.postinst: prune private information from
      installer log
    - src/utils/ecryptfs-setup-private: don't echo passphrase if running in
      bootstrap mode
    - CVE-2009-1296
  * src/utils/ecryptfs-setup-private: make some of the lanuage more readable,
    (thanks, anrxc)
  * README, configure.ac, debian/control, debian/rules,
    doc/sourceforge_webpage/README, src/libecryptfs-swig/libecryptfs.py,
    src/libecryptfs-swig/libecryptfs_wrap.c,
    src/libecryptfs/key_management.c, src/libecryptfs/libecryptfs.pc.in,
    src/libecryptfs/main.c, src/pam_ecryptfs/Makefile.am,
    src/utils/manager.c, src/utils/mount.ecryptfs.c: move build from gcrypt
    to nss (this change has been pending for some time)
  * src/utils/ecryptfs-dot-private: dropped, was too hacky
  * ecryptfs-mount-private.1, ecryptfs-setup-private.1: align the
    documentation and implementation of the wrapping-independent feature,
    LP: #383746
  * src/utils/ecryptfs-umount-private: use keyctl list @u, since keyctl show
    stopped working, LP: #400484, #395082
  * src/utils/mount.ecryptfs_private.c: fix counter file locking; solves
    a longstanding bug about "random" umount caused by cronjobs, LP: #358573

  [ Michal Hlavinka (edits by Dustin Kirkland) ]
  * doc/manpage/ecryptfs-mount-private.1,
    doc/manpage/ecryptfs-rewrite-file.1,
    doc/manpage/ecryptfs-setup-private.1, doc/manpage/ecryptfs.7,
    doc/manpage/mount.ecryptfs_private.1,
    doc/manpage/umount.ecryptfs_private.1: documentation updated to note
    possible ecryptfs group membership requirements; Fix ecrypfs.7 man
    page and key_mod_openssl's error message; fix typo
  * src/libecryptfs/decision_graph.c: put a finite limit (5 tries) on
    interactive input; fix memory leaks when asking questions
  * src/libecryptfs/module_mgr.c: Don't error out with EINVAL when
    verbosity=0 and some options are missing.
  * src/utils/umount.ecryptfs.c: no error for missing key when removing it
  * src/libecryptfs-swig/libecryptfs.i: fix compile werror, cast char*
  * src/utils/ecryptfs_add_passphrase.c: fix/test/use return codes;
    return nonzero for --fnek when not supported but used
  * src/include/ecryptfs.h, src/key_mod/ecryptfs_key_mod_openssl.c,
    src/libecryptfs/module_mgr.c: refuse mounting with too small rsa
    key (key_mod_openssl)
  * src/utils/ecryptfs_insert_wrapped_passphrase_into_keyring.c: fix return
    codes
  * src/utils/ecryptfs-rewrite-file: polish output
  * src/libecryptfs/key_management.c: inform about full keyring; insert fnek
    sig into keyring if fnek support check fails; don't fail if key already
    exists in keyring
  * src/utils/ecryptfs-setup-private: if th...

I am suspicious that this is a side effect of the commit below. This seems to limit results to those in specific namespaces.

  commit 1d1e97562e5e2ac60fb7b25437ba619f95f67fab
  Author: Serge E. Hallyn <email address hidden>
  Date: Thu Feb 26 18:27:38 2009 -0600

    keys: distinguish per-uid keys in different namespaces

I can't reproduce this as yet. With a plain, fresh pull from Linus' tree on a rhel5.3 system,
I get the following. Can you confirm that in your case, with the commands below, you do
not see the last line in the 'keyctl show' output?

with user namespaces:

[root@linuz11 ~]# keyctl add user mykey stuff @u
743079327
[root@linuz11 ~]# keyctl list @u
1 key in keyring:
743079327: --alswrv 0 0 user: mykey
[root@linuz11 ~]# keyctl show
Session Keyring
       -3 --alswrv 0 0 keyring: _ses
713825872 --alswrv 0 -1 \_ keyring: _uid.0
743079327 --alswrv 0 0 \_ user: mykey
[root@linuz11 ~]# uname -a
Linux linuz11.watson.ibm.com 2.6.31-rc3-00157-gaea1f79 #582 SMP Wed Jul 22 13:14:37 EDT 2009 s390x s390x s390x GNU/Linux

without user namespaces:

[root@linuz11 ~]# keyctl add user mykey stuff @u
113989424
[root@linuz11 ~]# keyctl list @u
1 key in keyring:
113989424: --alswrv 0 0 user: mykey
[root@linuz11 ~]# keyctl show
Session Keyring
       -3 --alswrv 0 0 keyring: _ses
653741632 --alswrv 0 -1 \_ keyring: _uid.0
113989424 --alswrv 0 0 \_ user: mykey

kirkland@x200:/local/virt/img$ keyctl add user mykey stuff @u
976692306
kirkland@x200:/local/virt/img$ keyctl list @u
1 key in keyring:
976692306: --alswrv 1000 1000 user: mykey
kirkland@x200:/local/virt/img$ keyctl show
Session Keyring
       -3 --alswrv 1000 1000 keyring: _ses
kirkland@x200:/local/virt/img$ uname -a
Linux x200 2.6.31-3-generic #19-Ubuntu SMP Tue Jul 14 16:07:02 UTC
2009 x86_64 GNU/Linux

:-Dustin

Using git://kernel.ubuntu.com/ubuntu/ubuntu-karmic.git, both with and without
CONFIG_USER_NS, it works for me:

[hallyn@linuz11 ~]$ keyctl add user mykey stuff @u
351981811
[hallyn@linuz11 ~]$ keyctl show
Session Keyring
       -3 --alswrv 501 501 keyring: _ses
456819210 --alswrv 501 -1 \_ keyring: _uid.501
351981811 --alswrv 501 501 \_ user: mykey
[hallyn@linuz11 ~]$ keyctl list @u
1 key in keyring:
351981811: --alswrv 501 501 user: mykey

Dustin, can you post your .config?

Also the result of

strace keyct list @u

Attached.

:-Dustin

Bisect shows the behavior changes as of the commit:

d84f4f992cbd76e8f39c488cf0c5d123843923b1 CRED: Inaugurate COW credentials

Since it is a by-product of such a huge change i assume it was inadvertent.

> kirkland@t61p:~$ keyctl show
> Session Keyring
> -3 --alswrv 1000 -1 keyring: _uid_ses.1000
> 698440950 --alswrv 1000 -1 \_ keyring: _uid.1000
> 575594151 --alswrv 1000 0 \_ user: 67354f2e3a6c1216
> 940463712 --alswrv 1000 0 \_ user: 1cb12fd405033223

Interesting. You shouldn't have seen this at all. PAM should have given you your own session keyring when you logged in, which should be called "_ses". "_uid_ses.<UID>" is the backup session keyring you fall back to if you don't get a session keyring for some reason.

PAM (pam_keyinit.so) should then make a link to the user keyring in the session keyring. This is done in userspace, not in the kernel.

Can you try stracing "su - kirkland" from root? I see:

keyctl(0x1, 0, 0xffffffffffffffff, 0xfcb, 0) = 355497645
keyctl(0x8, 0xfffffffc, 0xfffffffd, 0, 0x1132700) = 0

which is KEYCTL_JOIN_SESSION_KEYRING followed by KEYCTL_LINK.

David

Yes I maintain that on my RHEL5.3 partition (which is at the moment inaccessible) I couldn't
reproduce this with the latest kernel. The bisection was done on a SLES partition. So PAM
seems a very likely suspect. I think Tyler had mentioned something like that yesterday too.

So we're not using pam_keyinit.so.

Instead, we're using pam_ecryptfs.so to load the keys, and then mount
an ecryptfs home or private directory.

Perhaps we're doing something there.

When I run:
 # strace su - kirkland 2>/tmp/strace

I don't see any keyctl() calls at all.

:-Dustin

You should use both, pam_keyinit.so first, so that each log-in session gets its own session keyring. The kernel will, under some circumstances, give you a session keyring if you don't have one and are falling back to the user-session keyring - any call which modifies a keyring, for example, if given the session keyring special ID will create the session keyring if it does not exist.

Okay, after adding pam_keyinit.so just before pam_ecryptfs.so in the
PAM configuration, I now can see the two keyctl calls in the strace.

...
keyctl(0, 0xfffffffd, 0, 0x7f084e6c5280, 0x7fff8c4ba1b0) = 683056049
keyctl(0, 0xfffffffb, 0, 0x7fff8c4ba1b0, 0x169fd20) = 97213900
...

"keyctl show" still doesn't provide any useful information, while
"keyctl list @u" does.

Does the pam_ecryptfs.so code need to do anything different, now that
we're using pam_keyinit.so?

:-Dustin

> "keyctl show" still doesn't provide any useful information, while "keyctl list @u" does.

Example, please.

David

On my RHEL5.3 partition, /etc/pam.d/login has at the end:

session optional pam_keyinit.so force revoke

When I remove that line, keyctl show does not list the user keys. With that line,
it does. With 2.6.31-rc3.

@dustin -- to summarise the current position the kernel does seem to have changed behaviour, this may be deliberate. Our userspace differs from that in RHEL where it does work with a similarly configured kernel. ecryptfs is working ok with the mods, and the investigation continues centering on the pam config. I'll assume you'll let us know if there is a kernel issue here.