From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266610AbUHIOk3 (ORCPT ); Mon, 9 Aug 2004 10:40:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266731AbUHIOkS (ORCPT ); Mon, 9 Aug 2004 10:40:18 -0400 Received: from mx1.redhat.com ([66.187.233.31]:9160 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S266610AbUHIOgT (ORCPT ); Mon, 9 Aug 2004 10:36:19 -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 15:35:11 +0100 Message-ID: <32470.1092062111@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > > 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. > > I figured you would write to the file (a keyring id?) and it would return > a key id. What do you mean by return? You can't pass it back as write()'s return value. I suppose you could then arrange for the fd to be read():-/ > > 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... > > They would contain symlinks to keyring IDs. Yes, but given that the targets of the symlinks would not be in /proc, how do you concoct the symlink. I suppose you could assume "/sysfs/keys/" as the target, but that's not very nice. > > 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? > > No. The reason for suggesting this was because with a filesystem API, the > information is already available in userspace, and it would be quite > simple to enumerate it. As you said, it's not something that would happen > all the time, so it's not performance critical. But if you need a kernel > API for the same thing, it's a moot point. It would be quite an involved process to do this in userspace. You'd have to walk through a nest of keyrings, and you'd have to do a lot of file opening, and closing (possibly 2 per key: type and description, though these could be available through the same file) and reading of dirs and symlinks. Maintaining access controls would be fun though... How does the kernel then distinguish between a read and a search? David