Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264421AbTEPMA4 (ORCPT ); Fri, 16 May 2003 08:00:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264424AbTEPMA4 (ORCPT ); Fri, 16 May 2003 08:00:56 -0400 Received: from pub237.cambridge.redhat.com ([213.86.99.237]:55015 "EHLO warthog.warthog") by vger.kernel.org with ESMTP id S264421AbTEPMAq (ORCPT ); Fri, 16 May 2003 08:00:46 -0400 To: Linus Torvalds cc: David Howells , Dean Anderson , Trond Myklebust , Garance A Drosihn , Jan Harkes , David Howells , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2 In-Reply-To: User-Agent: EMH/1.14.1 SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Date: Fri, 16 May 2003 13:12:45 +0100 Message-ID: <12957.1053087165@warthog.warthog> From: David Howells Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6301 Lines: 145 > My take on this is that I'm personally totally uninterested in AFS and > Kerberos. A lot of people though are interested in network filesystems (of which AFS is but one example) and authenticating them (Kerberos is not unusual for this). AFS itself doesn't really give a rat's backside about PAGs. They exist solely within the client's deranged imagination as a means of coordinating sessions between the kernel and userspace AFAICT and they are also used as a basis for selecting cached credentials. > What I _am_ interested in is things like per-user VPN keys, and things > like keeping my local harddisk encrypted. Anything that can be used for network fs's (with distributed authority services) ought to be useful for purely local token management (where the authority is trivial). > So myt background is that unless the credentials are useful for something > like that, then they aren't useful AT ALL. I concur. > With a local encryption, what I'm perfectly willing to do is to go through > a "strong authentication" once, but once I've done that, I don't want to > do it again every time I log in to that machine. Are you requiring that the tokens be retained when you fully log out from a machine? > I use ssh all the time, and I have a few machines I trust, so when I come in > from such a trusted machine, and the strong authentication session is > already in progress, I don't want to see a password or anything like > that. It should "just work". I take it you're _not_ talking about transferring tokens from one machine to another as part of the ssh login. > And most importantly, it should "just work" _without_ having to have some > central service have to know about it. I'm a big believer in _not_ having > deamons that keep track of something and having to connect to them. I'm ok > with a "ssh-agent", but I absolutely _abhor_ linkages, and if that ssh > agent has to know about some "super-agent", and that "super-agent" has to > talk to my "disk-agent", then you have a total disaster on your hands. So you copy /etc/passwd around by hand every time you change your password rather than using NIS, YP, Kerberos, SMB or whatever? OTOH, with a large organisation with lots and lots of computers, by using something like this a user should be able to log in anywhere, change their password anywhere, etc without running the sysadmins ragged. Or am I misunderstanding you? Are you talking about local daemons for keeping hold of the tickets you've been granted by remote authorities? If that's the case, then yes, I agree with you, but I haven't suggested such a thing is necessary. I don't believe Kerberos, for instance, needs such a thing, but I may be wrong. > So I think I should be able to write a small PAM agent that automatically > joins me with the right keys when I log in. This is my requirement. And > part of that requirement is that my PAM agent should _not_ have to know > about _other_ agents that may also be adding and removing keys. There > should be no "linkages" between different key spaces, yet they should be > able to use the same basic kernel infrastructure to maintain them. Sort of like login reads /etc/groups to find out which groups you're in and then calls setgroups() to load them into the kernel? Actually, what you're describing sounds like it may have a race, but probably not one that's significant. What happens if two login sessions for the same user try to happen simultaneously and both immediately see that the default keyring for that doesn't yet exist? > And this is where naming becomes important. Because there should be no > linkages, I think the ad-hoc naming is a bug. My PAM module shouldn't > have to ask somebody else what key ID's to use. It knows who I am, it > should know where to add my keys. And it should be able to add my keys > _without_ being in the way of somebody else adding keys. Sounds like keyrings need names and ACLs (at the very least an owner UID). > And when I add a key in one window, I want that key to be available in the > other windows that were opened with independent SSH sessions. Again, > without having to go through some super-agent to figure things out. The > kernel _is_ the agent, and if we're adding key knowledge, we should do it > right. Fair enough... mostly. You still have to be able to prevent it from been added under some circumstances. > If I want just _one_ session to get some special powers (let's say that I > do the equivalent of "su", except I do it by adding the proper credentials > to my session instead of by changign to root user), then I should be able > to just do > > new-session /* creates a new local keyring at the top of the > credentials stack */ > add-key xxxx /* adds a new key to the top keyring - and because > the top keyring now isn't my default one, other > ssh sessions won't be seeing this key */ > > but if I do _just_ the > > add-key xxxx > > then I want that key to show up in all my other sessions too, because now > I'll be adding a key to my "default session". And it also shows up in the > window where I have even _more_ capabilities - the "new-session" didn't > drop my old capabilities, it just created a space to hold even more > (independent) keys. Hmmm... Do you envision a strict stack? Or a manipulatable sequence? Take a SUID program for instance, do you want the SUID credentials to override the pre-exec credentials until discarded (at which point there's no way to retrieve them)? Or do you envision the following "commands": (*) new-session [] Create a new private keyring or session, potentially with ACL governing joining, modification, etc. by users and/or groups. (*) list-sessions List keyrings available to this process (*) list-keys List keys in the available session (*) upgrade-session Move session to front of sequence. Becomes provider of UID/GID for this process. (*) add-key [--session ] Add a key to the primary or named session. 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/