Peter Seebach wrote:
> In message <20030828042834.32D4BA60C@zen.crufty.net>, Simon J. Gerraty writes:
> >Sorry for being vague, I was trying to avoid saying "this is how template
> >users are implemented using PAM" since I didn't want to fan any flames ;-)
> 
> Ahh.  :)
> 
> >To clarify, one of the stated advantages of PAM is the ability to modify
> >the state of the process wanting authentication.   Now the template user
> >thing is pretty simple to implement in PAM, but provided BSD Auth has a means
> >of communicating back to the calling process other than via the exit status
> >of the authenticator, it should be possible to do there too.
> >But I'm not familiar with BSD Auth, so I was asking about the communication
> >path(s) between the process wanting authentication and the authenticator
> >process.
> 
> I think there are ways to get things like that.  I don't know for sure what
> the easy way to do it is.
> 
> -s

Though not directly related.

Checkpassword interface comes to mind. Three pieces maybe involved:
credential_collector/supervisor -> checkpassword -> authenticated_service.

Credential collector program reads credentials, and writes them to
descriptor 3, then fork/execs/supervises checkpassword. checkpassword
then read them, authenticates and exits on failure/errors,
or execs the authenticated service. Authenticated service then
may be allowed to have the environment as passed down the fork/exec.
argv and environ for example. There you go, ability to modify the state
of a process wanting authentication - fork and exec plus supervision to
boot.