On Fri, 12 Sep 2003, Love wrote:

> Jason Thorpe <thorpej@wasabisystems.com> writes:
>
> > On Thursday, September 11, 2003, at 01:23  PM, Greg A. Woods wrote:
> >
> >> However I've not yet seen one shred of evidence which would show that
> >> there could be any kind of problem with implementing PAM afterwards or
> >> even with implementing PAM support via a BSD Auth proxy authenticator.
> >
> > What sort of evidence do you need other than "some authenticators need
> > to modify the context of the process".  You can't currently do that
> > with the proxy scheme used by BSD Auth.
> >
> > If you have a solution for this problem, hey, we're all ears.
>
> I would say that there should be something like the setenv but instead a
> callfunc module stringargument (module magic sent up over the fd that binds
> togther libbsdauth and the autheticating module). And then the libbsdauth
> lib should dlopen module in /lib/whever/lib<module>.so and dlsym
> <somesymbol> an call that with the argument <stringargument>.
>
> This is of course just oneway, I guess it could be make twoway someway.

Huh, that didn't make sense. ??

The problem is that PAM modules can DO ANYTHING in the process's address
space. Some folks see that as a reason to avoid PAM, some folks see that
as a strength.

The problem (for supporting PAM) is that BSD Auth does everything in a
separate address space.  So any such fixup has to get copied to the
original address space. Well, 1) BSD Auth limits what changes can get
propagated back to the original process; what happens if the PAM module
does something that can't get copied back? 2) How do you necessarily
_tell_ what got changed? PAM modules don't have to tell the host program
what they did, so it's not that easy.

Take care,

Bill