Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266285AbUFPOW6 (ORCPT ); Wed, 16 Jun 2004 10:22:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266286AbUFPOW6 (ORCPT ); Wed, 16 Jun 2004 10:22:58 -0400 Received: from mx1.redhat.com ([66.187.233.31]:45993 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S266285AbUFPOWm (ORCPT ); Wed, 16 Jun 2004 10:22:42 -0400 From: David Howells In-Reply-To: <3943FF92-BEFE-11D8-95EB-000393ACC76E@mac.com> References: <3943FF92-BEFE-11D8-95EB-000393ACC76E@mac.com> <1087282990.13680.13.camel@lade.trondhjem.org> <772741DF-BC19-11D8-888F-000393ACC76E@mac.com> <1087080664.4683.8.camel@lade.trondhjem.org> <1087084736.4683.17.camel@lade.trondhjem.org> <87smcxqqa2.fsf@asterisk.co.nz> <8666.1087292194@redhat.com> To: Kyle Moffett Cc: Blair Strang , Linus Torvalds , lkml Subject: Re: In-kernel Authentication Tokens (PAGs) 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, 16 Jun 2004 15:22:21 +0100 Message-ID: <9960.1087395741@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2317 Lines: 66 > One thing that I would very much like to have is the ability to create a new > shell with a new keyring, such that I can still see and use the old keyring, > but I can create new keys without modifying the old keyring, even to the > extent of masking out keys in the old keyring without modifying them for > other processes. From my brief glance at your patch, that's not a feature > you have implemented. Hmmm... What exactly are you wanting to do? Each task theoretically subscribes to five keyrings (the group one isn't yet there) in this model; three of which are transferred across a fork, and four across CLONE_THREAD. The five keyrings are: - Group (associated with primary GID) - User (associated with UID) - Session (voluntarily discarded) - Process (shared between threads in a process) - Thread (one per thread) > I would also like the ability to mark a key as unreadable except by kernel > threads or processes with CAP_KEYRING. What do you mean by "unreadable"? Currently, userspace can't see the data attached to a key. It can only see the description, and only then through /proc/keys. > If I can pass key "handles" of some sort over UNIX sockets, then I can also > pass an unreadable key to a daemon process which uses it to access my files > until I revoke the key. I can see what you're getting at. I think I need to create some more operations: (*) Retire/Revoke key (*) Add key to another keyring (*) Remove key from keyring (*) List keyring (*) Describe key (*) Read key (if not protected) (*) Create keyring I have pondered representing keyspace with some sort of filesystem interface (using vfs ops to represent the operations), but that could require hardlinked directories (keyrings) to pull off - either that or symlinks. Also, there's the problem of security on the operations themselves. How do you determine what a process is allowed to do? Either I should only allow access to keys and keyrings to which a process is subscribed, or I should attach UID/GID/MASK values to every key and keyring. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/