lkml.org 
[lkml]   [2004]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.403 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site