Mikhail Teterin <[EMAIL PROTECTED]> writes:
> The pam_setenv and pam_putenv are backwards, IMHO. putenv should be
> using setenv -- not the other way around. Currently, the setenv takes
> NAME and VALUE separately, mallocs a new buffer, sprintfs %s=%s into it,
> sends the buffer to putenv, which re
> Mikhail Teterin <[EMAIL PROTECTED]> writes:
> > The following patch fixes (works around?) the problem for me
> > (pam_setenv is rather inefficiently implemented by the vendor, BTW),
> I am the vendor. What's wrong with pam_setenv()?
I only went into the code to see where it may be crashing my
Mikhail Teterin <[EMAIL PROTECTED]> writes:
> The following patch fixes (works around?) the problem for me (pam_setenv
> is rather inefficiently implemented by the vendor, BTW),
I am the vendor. What's wrong with pam_setenv()?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send
The rshd started to crash on my system after the recent -current
upgrade. It does not dump core (why?), but with a lot of syslog() I
narrowed the trouble spot down to the pam_setenv() calls -- the very
first one of them, in rshd.c never returned... The libpam is:
/usr/lib/libpam.so.2:
$FreeBS