On May 7, 10:16am, Greywolf wrote:
} [Thus spake Jason Thorpe ("JT: ") 6:41pm...]
} JT: On Jan 17, 2005, at 4:06 PM, Greywolf wrote:
} JT:
} JT: > While we're here, is there a way to configure the system in such a way
} JT: > that one does not HAVE to use @#%*^ PAM?
} JT:
} JT: Once we have adapted all of the system utilities, PAM will become as
} JT: optional as nsswitch (that is to say "not at all").
} 
} So PAM is going to force dynamic loading in the root utilities, thus

     This was decided some time ago and was done for 2.0.  

} preventing one from building one's /bin and /sbin statically, and there

     You already have to do a custom build of the system if you want
this in 2.0.

} is nothing one can do to say "don't build with PAM because I do not want
} it"?

     You can, but the system probably won't work.

     However, PAM isn't the only thing pushing the system this way.
There is also dynamic nsswitch which will be along soon, and the I18N
project (Citrix?).  The bottom line is that to have a fully functional
modern system, it pretty much has to be dynamic.

} *sigh*.  I guess the people who were convinced that PAM is not a win
} weren't as convincING that PAM is not a win.  Pity.  I really fail to
} see a universal gain from this.

     The universal gain would be that authentication code can be kept
in one place making the system easier to maintain and support, third
applications automatically use whatever authentication method the
administrator wants without having to implement all possible
authentication methods, and the administrator now has control over the
way authentication is done and can easily add esoteric methods such as
authenticating against a RADIUS server or a Windows box.

     The flip side is that by default the system will behave exactly
the same way as it does now, so unless you go looking for it, you won't
even know PAM is there.

}-- End of excerpt from Greywolf