From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263743AbUHIJeQ (ORCPT ); Mon, 9 Aug 2004 05:34:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266364AbUHIJeQ (ORCPT ); Mon, 9 Aug 2004 05:34:16 -0400 Received: from mx1.redhat.com ([66.187.233.31]:59545 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S263743AbUHIJeN (ORCPT ); Mon, 9 Aug 2004 05:34:13 -0400 From: David Howells In-Reply-To: References: To: James Morris Cc: Andrew Morton , torvalds@osdl.org, linux-kernel@vger.kernel.org, arjanv@redhat.com, dwmw2@infradead.org, greg@kroah.com, chrisw@osdl.org, sfrench@samba.org, mike@halcrow.us, trond.myklebust@fys.uio.no, mrmacman_g4@mac.com Subject: Re: [PATCH] implement in-kernel keys & keyring management [try #2] 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:33:50 +0100 Message-ID: <15907.1092044030@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org James Morris wrote: > Implement a filesystem interface, e.g. /proc//keys > > From here you can have: > > /create How would this work? Remember you've got to get some data back, and you've got to simultaneously attach your key to a keyring, otherwise it'll just be erased immediately. > //update > /revoke > /chown > /chmod > ... I could. You're going a little far: chown and chmod can be done by other methods on the / directory. > Rather than syscalls/prctls for each of these. It'd require a lot more code and memory to do it with a filesystem, I think. > For keyrings, you could have: > > /proc//keyring/thread > /session > /process > ... What are these? Files containing keyring ID numbers? If so, better to just have one file from whence you can read all the IDs, and since /proc/pid/status has to grab the requisite lock anyway... > Instead of having /proc/keys and associated locking/seqfile overhead in > the kernel, a userspace library could instead traverse /proc to build a > global list of keys. And incur even more locking overhead? Besides, why? Looking at all the keys on the system isn't something that should be done very often, and what you're suggesting would be more expensive in the long run. > In general, I think you may be able to move logic out of the kernel this > way, e.g. userspace searching for keys. But you need to lock the keyrings as you search. Access controls also need to be enforced, but that could probably be done in userspace (you can't scan the contents of a keyring you don't own). Besides, the search _has_ to be available in kernel space. A filesystem such as AFS or NFS would need to be able to call it during file->open(), and maybe at other times. Would you suggest that it should call out to userspace to do the keyring search? Or would you, say, suggest a new open() syscall that takes a key ID in addition? And since there has to be a kernel space search routine, why not make it available to userspace too? David