CRED: Fix prepare_kernel_cred() to provide a new thread_group_cred struct
Fix prepare_kernel_cred() to provide a new, separate thread_group_cred struct
otherwise when using request_key() ____call_usermodehelper() calls
umh_keys_init() with the new creds pointing to init_tgcred, which
umh_keys_init() then blithely alters.
The problem can be demonstrated by:
# keyctl request2 user a debug:a @s
249681132
# grep req /proc/keys
079906a5 I--Q-- 1 perm
1f3f0000 0 0 keyring _req.
249681132: 1/4
38ef1626 IR---- 1 expd
0b010000 0 0 .request_ key:
ee1d4ec pid:4371 ci:1
The keyring _req.XXXX should have gone away, but something (init_tgcred) is
pinning it.
That key actually requested can then be removed and a new one created:
# keyctl unlink
249681132
1 links removed
[root@andromeda ~]# grep req /proc/keys
116cecac IR---- 1 expd
0b010000 0 0 .request_ key:
eeb4911 pid:4379 ci:1
36d1cbf8 I--Q-- 1 perm
1f3f0000 0 0 keyring _req.
250300689: 1/4
which causes the old _req keyring to go away and a new one to take its place.
This is a consequence of the changes in:
commit
879669961b11e7f40b518784863a259f735a72bf
Author: David Howells <dhowells@redhat.com>
Date: Fri Jun 17 11:25:59 2011 +0100
KEYS/DNS: Fix ____call_usermodehelper() to not lose the session keyring
and:
commit
17f60a7da150fdd0cfb9756f86a262daa72c835f
Author: Eric Paris <eparis@redhat.com>
Date: Fri Apr 1 17:07:50 2011 -0400
capabilites: allow the application of capability limits to usermode helpers
After this patch is applied, the _req keyring and the .request_key key are
cleaned up.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>