Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: slow su? [solved]

On Jan 3,  1:21pm, David Holland 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.

     If I recall right, my reading of the PAM spec was that it should
ignore missing modules, but I don't have the spec in front of me at the
moment.  When I asked you about it, you just handwaved and said that
somebody you know that is supposedly a PAM expert said it would be a
bad idea without providing any details.  I sure would like to know why
we shouldn't just follow the spec...

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

     That's like saying NFS ought to go.  PAM is an expected part of a
modern OS and a lot of third party code uses it.  At the very least,
you would need to provide the client side API.  And, ideally, you would
need to provide some way of modularising authentication.  There are
plenty of third party PAM module out there making PAM the ideal way.
Otherwise, you force people to make their own modules, and that could
cause people to discard NetBSD as a choice of OS.

     In the pre-PAM days, I ended up using Redhat for a project because
it did have PAM and that made the project much easier.  I would have
liked to have used NetBSD, but without PAM I would have had to do a lot
of custom coding.

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

     It becomes the job of the person changing the system to make the
necessary adjustments.

}-- End of excerpt from David Holland

Home | Main Index | Thread Index | Old Index