Subject: Re: RFC: migration to a fully dynamically linked system
To: None <tech-userlevel@netbsd.org>
From: None <kpneal@pobox.com>
List: tech-userlevel
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 kpneal@pobox.com 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:
1) username
2) password
3) some form of domain or other name
4) ???

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
4) ???

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

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"