[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: slow su? [solved]
On Wed, 10 Aug 2011 06:43 +0000, "David Holland"
> On Wed, Aug 10, 2011 at 08:25:54AM +0200, Ian D. Leroux wrote:
> > Since updating my amd64 system to the latest -current two weeks ago
> > su(1) has been taking ~30s to display the "password" prompt.
> > Otherwise it works normally.
> My first instinct would be to rebuild su without PAM and see if that
> makes the problem go away. [...] and also check if you've accidentally
> turned on Kerberos.
Thank you all for your suggestions, which were indeed helpful. As
expected, it wasn't a bug but a PEBKAC. For the record:
- I have /usr/pkg/bin before /usr/bin in my path
- Some handy desktop apps depend on curl, which depends on heimdal,
which installs a /usr/pkg/bin/su
- At my last update I set MKKERBEROS=no.
So when I ran "su", I was getting a kerberised /usr/pkg/bin/su that took
forever because it was waiting for a non-kerberised base system.
/usr/bin/su runs normally, prompting for a password instantly.
The scary part is that I was running a non-base-system su for months
without realising it until I ktraced su and discovered that the path
search was stopping in /usr/pkg/bin. It was an uncomfortable reminder
of the valuable part played by the pkgsrc committers in keeping
malicious software off my system. Mounting the directories on my $PATH
read-only in normal operation won't help much if pkgsrc helps me install
the trojan there myself.
For now, I'll just revert to the conventional (base system first) path
ordering. I had reversed it to ensure that up-to-date versions of
pkg_add and company supersede the base system ones, avoiding package
format version problems in pkg_comp, but this is presumably no longer
necessary now that I track -current and can get the latest pkg_add in
the base system.
Main Index |
Thread Index |