Re: slow su? [solved]

["Ian D. Leroux" <idleroux%fastmail.fm@localhost>]

On Wed, 10 Aug 2011 06:43 +0000, "David Holland"
<dholland-current%netbsd.org@localhost> wrote:
> 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.

Thanks,

Ian Leroux