From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268176AbUHKTKl (ORCPT ); Wed, 11 Aug 2004 15:10:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268178AbUHKTKl (ORCPT ); Wed, 11 Aug 2004 15:10:41 -0400 Received: from mx1.redhat.com ([66.187.233.31]:22704 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S268176AbUHKTKg (ORCPT ); Wed, 11 Aug 2004 15:10:36 -0400 From: David Howells In-Reply-To: <16655.1092227651@redhat.com> References: <16655.1092227651@redhat.com> <5788.1092160798@redhat.com> <16109.1092044758@redhat.com> Cc: Linus Torvalds , akpm@osdl.org, James Morris , 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 , viro@parcelfarce.linux.theplanet.co.uk Subject: [PATCH] keys & keyring management: key filesystem 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: Wed, 11 Aug 2004 20:10:08 +0100 Message-ID: <1541.1092251408@redhat.com> To: unlisted-recipients:; (no To-header on input) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Here's a preliminary look a patch I've concocted to make keys accessible through yet another filesystem (TM). At the moment, it only gives a read-only view onto the keys in the system. The patch can be found at: http://people.redhat.com/~dhowells/keys/keyfs-268rc2.diff.bz2 It requires the keys-268rc2-6.diff.bz2 patch to supply the basic key services. Currently, it makes a filesystem that looks like: /keyfs/ thread [symlink to process's thread key] process [symlink to process's process key] session [symlink to process's session key] user [symlink to user key for process's UID] user-session [symlink to def session key for process's UID] / [directory representing a key] type [file holding key type as a string] description [file holding key description as a string] expiry [file holding key expiry time as a decimal string] perm [file holding key access mask as an octal string] payload [file permitting reading/writing of key's payload data] / [directory representing a keyring] type [file holding key type as a string] description [file holding key description as a string] expiry [file holding key expiry time as a decimal string] perm [file holding key access mask as an octal string] keyring/ [directory representing a keyring's contents] [symlink to linked keys] I've encountered some problems: (1) readdir() on the root directory has to run in O(N^2) time because the key tree lock is a spinlock and the filldir call is permitted to sleep. I could solve this by making the spinlock into a semaphore, and just read-locking it for the duration of the whole readdir call. But this has other problems: it'll exclude any key changes for the duration, especially if calling filldir causes it to swap a lot. I don't think global enumeration is necessarily a good idea. /proc/keys is a debugging interface, to be made root readable only at some point. I don't think you should be able to _see_ any keys you don't have any rights to. Do people disagree with that? (2) It weakens security to some extent: it makes keys more accessible, more visible. I could, perhaps, deal with this by filtering the keys in readdir() and lookup() on the root directory. (3) The key permissions mask doesn't map easily to the usual RWX bits on a file with their strictly VFS meaning. Whilst on a key I'm using the 'X' bits to indicate search permission, that can't directly control execute permission on the key directory. (4) Accessing keys this way requires more syscall invocations, more locks to be dealt with, etc. than the syscall approach. It's a lot less efficient, particularly when it comes to producing a list of the same data seen in /proc/keys. (5) The kernel filesystem side of this is already much bigger than the syscall/prctl approach, even when it's read-only. (6) d_revalidate and getattr need to be supplied for any file or directory that relates to a particular key to pick up UID/GID/permissions changes. This is difficult to avoid. Each key has to be represented by several inodes, and they all need to be kept in sync. I still haven't seen any really good arguments why I should get rid of all the syscalls/prctls and drive it from userspace _entirely_ through a keyfs. We seem to be going a little overboard with the "everything must be a filesystem approach". I could perhaps make all the key syscalls ioctls on a control file placed in the root directory:-) David