Subject: Re: RFC: migration to a fully dynamically linked system
To: None <firstname.lastname@example.org>
From: None <email@example.com>
Date: 12/30/2001 20:40:52
On Sun, Dec 30, 2001 at 01:51:54PM -0800, Bill Studenmund wrote:
> On Sat, 29 Dec 2001 firstname.lastname@example.org wrote:
> > How terrible would it be to move authentication out of "all" programs and
> > into an "authentication program"? There could be an API of sorts to
> > communicate between the application and the authenticator.
> Because you then have to spread the data receiving code over all of the
> programs. While it would probably be smaller than the authenticator code
> itself, we still are faced with the same fundamental problem. If you want
> to add a new authentication scheme that needs to receive different data,
> you have to change every program. While the code footprint would be
> smaller, the problem is still the same. :-(
Um, what data would be needed? How much can be hidden in a library?
To authenticate a user you would need some of these things:
3) some form of domain or other name
In return applications could get back:
1) valid/invalid, expired password, expired account, etc etc.
2) other data, like being instructed to set an environmental variable to
some specific value.
3) perhaps an opaque cookie
Also useful would be a way to destroy any cached authentication data,
like when a user logs out. Perhaps an opaque cookie would be useful
What other data would be necessary? That's a serious question. Or,
is there a way to put other data into a format that can be handed
back to applications without them having to have too-specific knowledge
of that data?
The API for clients would be in a library I'm sure. It would be a lot
easier if a statically linked program could be brought up to current
authentication methods by simply relinking.
(Secret hidden desire of mine: I don't like having Kerberos tickets
sitting around in /tmp. I'd rather they be someplace inaccessible
to an attacker.)
Kevin P. Neal http://www.pobox.com/~kpn/
"It sounded pretty good, but it's hard to tell how it will work out
in practice." -- Dennis Ritchie, ~1977, "Summary of a DEC 32-bit machine"