Re: slow su? [solved]

["Roland C. Dowdeswell" <elric%imrryr.org@localhost>]

On Sat, Aug 13, 2011 at 09:09:44PM +0000, Christos Zoulas wrote:
>

> > > Being a stubborn fellow, I'll probably try commenting out all references
> > > to pam_ksu and pam_krb5 in /etc/pam.d/* and see whether that improves
> > > matters.  If it does, perhaps an ed script to do the same could be run
> > > as part of the build process when Kerberos is disabled?
> >
> >It could; the problem (or a problem) is that because those files are
> >in /etc the process of updating them in already-installed systems is
> >"interesting".
> 
> I don't think that is necessary if you don't have a krb5.conf file.

I think that we should comment out the PAM Kerberos modules in the
default install.  Right now, we have hacked our Kerberos libraries
in a rather non-standard way to disable Kerberos if /etc/krb5.conf
is not present.  I believe that this hack was instituted before
PAM when our various tools (login, su, etc.) would unconditionally
attempt to validate Kerberos passwds causing nameservice lookups
and unnecessary delays.

The unfortunate result of this decision is that on NetBSD, you
cannot use Kerberos without an /etc/krb5.conf.  It is, however,
perfectly reasonable to be a Kerberos client without allowing
Kerberos logins on a box.  In fact, this is how I generally setup
my laptops.  It is also perfectly reasonable to run Kerberised
services on boxes which do not allow Kerberos passwd-based logins.
In fact, it is in general better to not allow Kerberos passwd-based
logins except on the console as in a Kerberised environment you
should not and should not have to broadcast your passwd to remote
machines.

So, I think that we should re-evaluate the PAM stacks, comment out
the Kerberos PAM modules from some, remove them from others and
remove the hack which disables Kerberos if /etc/krb5.conf is not
present.  Services such as sshd should check if their keytabs
contain the appropriate keys before advertising that they support
Kerberos and perhaps PAM modules should be likewise instrumented.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/