On Mon, 23 Nov 1998, der Mouse wrote:

: > [PAM] certainly simplifies a lot of development for portable
: > applications.
: 
: How?  Building shared objects is system-specific magic on every system
: I know of that has them....

Because it's used by more than just BSD/OS.  Note: `development for portable
_applications_', which has nothing to do with creating PAM shared objects.
>From Solaris's manpage pam(3):

     The PAM library interface  consists  of  six  categories  of
     functions,  the  names  for  which all start with the prefix
     pam_.

Though Solaris's implementation explicitly mentions shared objects, that
doesn't preclude our possible implementation as using various backend
interfaces.

It would be possible, maybe even trivial, to implement PAM backends that do
things inside the space of libc (/etc/passwd), in a shlib (SQL, RSA), and in
a BSDAuth compatible manner, all based on the configuration.

: * When linked static, dl_open() can't work unless/until we redo our
:    dynamic linker as a .a library for use by such applications.  (In my
:    mind, doing this defeats much of the purpose of linking static; when
:    I link something static I usually do it because I want a completely
:    self-contained executable.)  BSDAuth wins here.

BSDAuth only wins when you drop the `completely self-contained executable'
part, which is obviously not the case in either proposed authentication
system.

This comes down to a design issue; typically, you should expect shlibs to
work when you need an authentication method other than /etc/passwd, as the
only time other authentication methods should happen is multi-user.

: * Ease of constructing new auth methods and the flexibility available:
:    BSDAuth's design wins here too, since external programs can be C,
:    sh, perl, elisp, what have you, whereas new shared objects are much
:    more restricted.

`See above'.  PAM can certainly be implemented to allow this, with or
without BSDAuth compatibility.

: * Damage containment: what happens if the authentication method is
:    buggy (or trojaned)?  With BSDAuth, an auth method that crashes may
:    cause that auth method to fail, but that should be the worst that
:    happens; with PAM, an auth method that crashes will take down the
:    whole process.  With BSDAuth, the most a trojaned auth program can
:    do is authenticate sessions it shouldn't; with PAM, as soon as you
:    call it it can take over the whole process in toto; either is very
:    bad, but the latter seems slightly worse to me.

Heh.  And what happens if I install a trojan in /bin/ls?  ;)

Damage containment comes down to the decades-old trust requirement between
oftware provider and user.  Every authentication system has the possibility
of opening big wide holes; just think about when some trojan authenticates
"root".

There's no way I can say that either really has a win, or that any auth
software has a win unless it's completely contained in libc.

: As various people have pointed out, either method can in principle
: provide a hook to support the other.

Actually, BSDAuth cannot provide a hook to PAM unless the BSDAuth system
also implements PAM's function call interface for use in programs which can 
use PAM.

PAM's function call interface is rather robust, with multiple types of
authentication, service type differentiation, and even multiply-stacked
authentication types.

If you have access to a Solamis box, see pam.conf(4) and pam(3).

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)