Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

Linus Torvalds
2003-05-15T17:11:49Z

On Thu, 15 May 2003, David Howells wrote:
> >
> > No it isn't. You can't do independent joins, since as it is, the code has
> > an "all or nothing" approach.
>
> Independent joins aren't necessarily good either. They add lots of complexity
> and consume lots of kernel resources.

Independent joins are a _requirement_.

My take on this is that I'm personally totally uninterested in AFS and
Kerberos.

What I _am_ interested in is things like per-user VPN keys, and things
like keeping my local harddisk encrypted.

So myt background is that unless the credentials are useful for something
like that, then they aren't useful AT ALL.

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. 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".

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.

[ It's a total disaster that a lot of CS'y people like, with indirect
servers keeping track of other servers that actually do the keys, but I
think it's all complete crap. Once the kernel knows about the keys, you
shouldn't need that kind of indirection on the local machine. ]

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.

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.

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.

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.

If your thing can't do this, then I'm not interested. And the patch I've
seen so far can't do it.

Linus