Messages in this thread |  | | Date | Tue, 10 Aug 2004 23:37:30 -0700 | From | Chris Wright <> | Subject | Re: [PATCH] implement in-kernel keys & keyring management [try #5] |
| |
Hi David,
* David Howells (dhowells@redhat.com) wrote: > It can be found at: > > http://people.redhat.com/~dhowells/keys/keys-268rc2-5.diff.bz2
Here's a few comments/questions from first pass-thru. Looks good so far. I have yet to fully digest it all, or run your current patchset/toolset to play with it.
it's still tough to walk away from the idea that this is really close to a filesystem interface.
sys_keyctl prototype declaration in key.h? maybe in syscalls.h? also, the #else /* !CONFIG_KEYS */ for doesn't look right. i think the syscall should always be there, instead use cond_syscall. prctl case statement. are case ranges supported in all gcc versions that are valid for 2.6 kernel compilation? key_euid_changed/key_egid_changed will change the process_keyring even if it's just a thread which did the setuid/gid. this doesn't sound right. i'm a little confused by suid_keys(). it's sprinkled in various spots, yet the function does nothing. what's the intention there (esp. w.r.t. key_euid_changed)? e.g. placement in compute_creds is before the actual process uid updates are done. why check pid ==1 and uid ==0 in exec_keys? why not switch_uid_keyring for non root_session_keyrings? in alloc_uid_keyring, keyring_alloc failure for session_keyring leaks uid_keyring allocation. key_user can't be squished into user_struct? seems like the quota stuff could become setable from userspace (rlimit-like). /sbin/request-key should probably path configurable like /sbin/hotplug.
thanks, -chris - 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/
|  |