From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266364AbUHIJlJ (ORCPT ); Mon, 9 Aug 2004 05:41:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266425AbUHIJlJ (ORCPT ); Mon, 9 Aug 2004 05:41:09 -0400 Received: from mx1.redhat.com ([66.187.233.31]:23197 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S266364AbUHIJlC (ORCPT ); Mon, 9 Aug 2004 05:41:02 -0400 From: David Howells In-Reply-To: References: To: James Morris Cc: torvalds@osdl.org, akpm@osdl.org, linux-kernel@vger.kernel.org, arjanv@redhat.com, dwmw2@infradead.org, greg@kroah.com, Chris Wright , sfrench@samba.org, mike@halcrow.us, Trond Myklebust , Kyle Moffett Subject: Re: [PATCH] implement in-kernel keys & keyring management User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Date: Mon, 09 Aug 2004 10:40:32 +0100 Message-ID: <16013.1092044432@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org James Morris wrote: > Here's some more feedback: > > typedef int32_t key_serial_t; > > Why is this signed? So I can have special values that are negative. I suppose it doesn't really matter - they could be small positive numbers or something, but then if I want to add one later, you get the possibility of overlap on a userspace that supports one running with a kernel that doesn't. > And does this really need to be a typedef? (Do you forsee it ever changing > from 32-bit?). No... but then 640KB of memory is enough for anyone, right? :-) > 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. Maybe. Though I think request_key() should follow the form of similar functions inside the kernel, such as request_firmware(). > I would suggest that the /sbin/request-key interface be done via Netlink > messaging instead. Other people argued the exact opposite first. > > #define sys_keyctl(o,b,c,d,e) (-EINVAL) > > This should probably be -ENOSYS. If it becomes a real syscall rather than being a subset of prctl(), then yes. > - capable(CAP_SETGID)) > + capable(CAP_SETGID)) { > new_egid = egid; > + } > > This looks superfluous. Yes. I had added an additional statement into there at one point. > 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. True. I don't know much about LSM though. David