[lkml]   [2004]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] implement in-kernel keys & keyring management [try #5]
Hi David,

* David Howells ( wrote:
> It can be found at:

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

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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