Re: slow su? [solved]

[christos%astron.com@localhost (Christos Zoulas)]

In article <20110813184531.GA27925%netbsd.org@localhost>,
David Holland  <dholland-current%netbsd.org@localhost> wrote:
>On Fri, Aug 12, 2011 at 09:55:12PM +0200, Ian D. Leroux wrote:
> > > On Thu, Aug 11, 2011 at 09:11:41PM +0200, Ian D. Leroux wrote:
> > >  > Otherwise, you're liable to get bitten someday when the old
> > >  > kerberised PAM modules left behind by your first installation stop
> > >  > working, the PAM stacks fail to load and su (and probably other
> > >  > valuable bits of the system as well) refuse to run.
> > >  > 
> > >  > This is implicit in the NOTES section of pam.conf(5), but easily
> > >  > overlooked.
> > > 
> > > See PR 40599...
> > 
> > Precisely.  I take it that there has been no progress on the matter
> > in the last two years?
>
>Yup. I was told that the fix I proposed (causing missing modules to
>always fail) was unacceptable. Apparently the PAM semantics are so
>fragile that any change to make it more robust also makes it fail open
>in obscure ways, or something like that.

This is not the problem... The problem is that a missing "binding",
"required", or "requisite" module should cause a failure, and most
modules are by design that.

>My opinion remains that PAM ought to go, but that's not trivial...

And replace it with what?

> > 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.

christos