Messages in this thread | | | Date | Sun, 8 Aug 2004 01:14:14 -0400 (EDT) | From | James Morris <> | Subject | Re: [PATCH] implement in-kernel keys & keyring management |
| |
On Sat, 7 Aug 2004, David Howells wrote:
> I've made available a patch that does a better job of key and keyring > management for authentication, cryptography, etc.. I've added a good bit of > documentation and I've commented the code more thoroughly.
Here's some more feedback:
typedef int32_t key_serial_t;
Why is this signed? And does this really need to be a typedef? (Do you forsee it ever changing from 32-bit?).
For consistency, request_key(), validate_key() and lookup_key() should probably be of the form key_request() etc. There are other similar cases throughout the code.
I would suggest that the /sbin/request-key interface be done via Netlink messaging instead. The kernel would generate key create and key update messages, to which userpace daemons can respond (similar to e.g. pfkey acquire). I think these messages need to be tagged with the key 'type', so that the userspace code knows what to generate keys for.
#define sys_keyctl(o,b,c,d,e) (-EINVAL)
This should probably be -ENOSYS.
- capable(CAP_SETGID)) + capable(CAP_SETGID)) { new_egid = egid; + }
This looks superfluous.
We need to look at the implications for LSM, e.g. keys have Unix style access control information attached, and LSM apps may want to extend this to other security models. Some of the user interface calls may also need to be mediated via LSM.
- James -- James Morris <jmorris@redhat.com>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |