Re: [PATCH] implement in-kernel keys & keyring management [try #5]

[Chris Wright]

Hi David,

* David Howells (dhowells@xxxxxxxxxx) 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/