On Jun 13,  9:17am, Peter Seebach wrote:
} In message <200301212040.h0LKeVnR001992@vtn1.victoria.tc.ca>, John Nemeth write
} s:
} >     There have been a number of complaints about potential security
} >issues.  A big one has had to do with PAM operating within the
} >environment of the program wanting to do authentication.  However, if
} >this is a problem, then an unauthorised person is already root, has the
} >ability to place arbitrary files on the system, or the administrator
} >has really screwed up the permissions on the PAM modules.  Either way,
} >the game is already over, and it isn't a PAM problem (i.e. the problem
} >is neither mitigated nor made worse by the presence of PAM).  The last
} >problem could be mitigated by the PAM library refusing to load modules
} >with inappropriate permissions.
} 
} Hmm.  I'm a bit confused.  One of the reasons that BSD/OS's BSD Authentication
} uses external programs for authentication is so that the program doing the
} authentication check needn't be running as root - unless the authentication
} module wants to require it to.  How does PAM work for this?

     PAM modules are shared libraries that are dynamically loaded at
run time.  Which modules/libraries get loaded and in what order is
determined by a configuration file.  This can be determined on a per
app basis

     A "files" module would most likely simply use getpwent() or
directly read /etc/spwd.db.  Obviously for this to work the program
doing the authentication would have to be running as root.  However,
there is nothing stopping a module from fork()ing and exec()ing a
setuid helper app.  But, as I noted earlier, then you have a different
problem, which is secure inter-process communication.

}-- End of excerpt from Peter Seebach