Can I "live" without PAM ? I need to implement a server with common web services (http with apache, ftp with pureftp, mail with Courier and Postfix, dns with bind) that I plan to administrat with ISPman that mantains an LDAP database for all setings and accounts.
I whant every service to authenticate with users_email against the LDAP database, where I expect to solve my problems with postfix that I didn't got to compile (in RH7.3) with sasl support but hop it will work with OpenPKG version. C�pia Thomas Lotterer <[EMAIL PROTECTED]>: > On Mon, Dec 08, 2003, [EMAIL PROTECTED] wrote: > > > I thought pam was a good authentication method used by lots of distros > as standard. > > It seams to me that OpenPKG prefers to default there packages to not > support PAM. > > Is there a known reason for that choice ? > > > Alex, > I don't have a complete list, but I'm aware of some issues. > > To support PAM, OpenPKG has to penetrate host system much deeper as we > would like it to do. This in contradiction to the OpenPKG philosophy > of > the least possible host tangency. We left the decision to the user and > made PAM support optional. > > Managing installation, configuration and removal of PAM applications > is somewhat painful as two incompatible configuration methologies > exist: one large config /etc/pam.conf file for all applications vs. > one dircetory /etc/pam.d with one file for every application. We tried > to abstract this mess using functionality provided by a separate "pam" > package. > > Also PAM in general is often only a partly solution for real > world applications. It is what the abbreviation says, "pluggable > authentication module", not more. You can use it to authenticate > existing users but the existence of the users must be provided by a > separate solution, i.e. NIS/YP for Unix "shell" accounts, which needs > additional setup. If you think nsswitch comes to the rescue, you're > wrong. Unlike PAM, it lacks support for a standardized API, some OS > like > FreeBSD 4.x do not support it at all for good reason. > > A better approach would be an application natively using LDAP. But as > there are alternatives like /etc/passwd, NIS, NIS+, RADIUS, TACACS to > name a few, any attempt will likely end up in huge application > rewriting > or limited support for identity management. But any native solution > renders PAM useless. > > PAM is also a system wide solution which is again in contradiction to > a OpenPKG philosophy, namely the independence of OpenPKG from the host > system and from a OpenPKG instance to other OpenPKG instances. > > Last but not least, PAM adds additional critical code pathes to > applications which are favored targets of security "inspection", see > "remote root exploit in openssh" [1] and "information leakage in > openssh" [2]. > > Having all that said I want you to know we understand there is a > need for PAM especially in enterprise installations that require > cross-platform identity management. So we do and continue to support > PAM. Just not by default. > > [1] http://www.openpkg.org/security/OpenPKG-SA-2003.042-openssh.html > [2] http://www.openpkg.org/security/OpenPKG-SA-2003.035-openssh.html > > -- > [EMAIL PROTECTED], Cable & Wireless > ______________________________________________________________________ > The OpenPKG Project www.openpkg.org > User Communication List [EMAIL PROTECTED] > ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List [EMAIL PROTECTED]
