Subject: Re: PAM
To: Ken Hornstein <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 09/25/2002 21:06:18
[ On Wednesday, September 25, 2002 at 13:24:07 (-0400), Ken Hornstein wrote: ]
> Subject: Re: PAM
> ... which is germane to this discussion. But before _you_ said that there
> were two solutions which had been "designed and implemented". Doesn't look
> like the token transfer has been implemented yet (and other than that, what
> he has now is essentially the AFS interface).
Yeah, well I was trying to find some way to say they weren't _both_
"designed _and_ _both_ implemented", but I got lazy.... ;-)
> Well, I haven't seen anything out of _YOU_ yet ... if I think the status
> quo is fine, do you really imagine me investing my time in a re-write?
I'm happy with static-linked code, and the current hacks seem to work
fine for me, though I would like to extend nsswitch a bit to allow
better control over and extensibility of the getpass() and
strcmp(crypt()) steps, eg. for s/key or other one-time password
schemes so that things like /usr/bin/login wouldn't need so many #ifdefs.
Give me a rea$on to inve$t my time and I'll produce the needed code! :-)
> >Douglas Engert has also implemented some interesting ideas in this area:
> > http://www.ornl.gov/~jar/dfs-afs.html
> But, unfortunately, Doug was only interested in getting DFS back
> to the same level of functionality that AFS had. From that document:
Yeah, but the important part is that his sec_login_set_context() call
affects the parent process, thus allowing for "pluggability" through
exec() of a separate (possibly static linked and possibly setuid)
binary. Done right it seems to me that the call to setpag() and even
the exec of the klog authenticator would be hidden in the nsswitch
callbacks done via libc in the ultimate parent of the PAG.
Greg A. Woods
+1 416 218-0098; <firstname.lastname@example.org>; <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; VE3TCP; Secrets of the Weird <email@example.com>