)]}'
{
  "commit": "995995378f996a8aa1cf4e4ddc0f79fbfd45496f",
  "tree": "ddc0c1305767e683535120361a5f5848b7ae3803",
  "parents": [
    "c5532b09bf40c398f2acfdd8f100c796d1d3f881"
  ],
  "author": {
    "name": "David Howells",
    "email": "dhowells@redhat.com",
    "time": "Mon Aug 22 14:08:33 2011 +0100"
  },
  "committer": {
    "name": "James Morris",
    "email": "jmorris@namei.org",
    "time": "Tue Aug 23 09:57:33 2011 +1000"
  },
  "message": "KEYS: If install_session_keyring() is given a keyring, it should install it\n\nIf install_session_keyring() is given a keyring, it should install it rather\nthan just creating a new one anyway.  This was accidentally broken in:\n\n\tcommit d84f4f992cbd76e8f39c488cf0c5d123843923b1\n\tAuthor: David Howells \u003cdhowells@redhat.com\u003e\n\tDate:   Fri Nov 14 10:39:23 2008 +1100\n\tSubject: CRED: Inaugurate COW credentials\n\nThe impact of that commit is that pam_keyinit no longer works correctly if\n\u0027force\u0027 isn\u0027t specified against a login process. This is because:\n\n\tkeyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0)\n\nnow always creates a new session keyring and thus the check whether the session\nkeyring and the user-session keyring are the same is always false.  This leads\npam_keyinit to conclude that a session keyring is installed and it shouldn\u0027t be\nrevoked by pam_keyinit here if \u0027revoke\u0027 is specified.\n\nAny system that specifies \u0027force\u0027 against pam_keyinit in the PAM configuration\nfiles for login methods (login, ssh, su -l, kdm, etc.) is not affected since\nthat bypasses the broken check and forces the creation of a new session keyring\nanyway (for which the revoke flag is not cleared) - and any subsequent call to\npam_keyinit really does have a session keyring already installed, and so the\ncheck works correctly there.\n\nReverting to the previous behaviour will cause the kernel to subscribe the\nprocess to the user-session keyring as its session keyring if it doesn\u0027t have a\nsession keyring of its own.  pam_keyinit will detect this and install a new\nsession keyring anyway (and won\u0027t clear the revert flag).\n\nThis can be tested by commenting out pam_keyinit in the /etc/pam.d files and\nrunning the following program a couple of times in a row:\n\n\t#include \u003cstdio.h\u003e\n\t#include \u003cstdlib.h\u003e\n\t#include \u003ckeyutils.h\u003e\n\tint main(int argc, char *argv[])\n\t{\n\t\tkey_serial_t uk, usk, sk;\n\t\tuk \u003d keyctl_get_keyring_ID(KEY_SPEC_USER_KEYRING, 0);\n\t\tusk \u003d keyctl_get_keyring_ID(KEY_SPEC_USER_SESSION_KEYRING, 0);\n\t\tsk \u003d keyctl_get_keyring_ID(KEY_SPEC_SESSION_KEYRING, 0);\n\t\tprintf(\"keys: %08x %08x %08x\\n\", uk, usk, sk);\n\t\treturn 0;\n\t}\n\nWithout the patch, I see:\n\n\tkeys: 3884e281 24c4dfcf 22825f8e\n\tkeys: 3884e281 24c4dfcf 068772be\n\nWith the patch, I see:\n\n\tkeys: 26be9c83 0e755ce0 0e755ce0\n\tkeys: 26be9c83 0e755ce0 0e755ce0\n\nAs can be seen, with the patch, the session keyring is the same as the\nuser-session keyring each time; without the patch a new session keyring is\ngenerated each time.\n\nReported-by: Greg Wettstein \u003cgreg@enjellic.com\u003e\nSigned-off-by: David Howells \u003cdhowells@redhat.com\u003e\nTested-by: Greg Wettstein \u003cgreg@enjellic.com\u003e\nSigned-off-by: James Morris \u003cjmorris@namei.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "a3063eb3dc232a16eab45161e28f0c88fc642841",
      "old_mode": 33188,
      "old_path": "security/keys/process_keys.c",
      "new_id": "3bc6071ad63352bde81e28b4338463497859f028",
      "new_mode": 33188,
      "new_path": "security/keys/process_keys.c"
    }
  ]
}