> 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 rshd and
noticed the mild inefficiency. Did not know where the code is from
either. Sorry if I offended you.
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-parses it and frees it.
I think, pam_setenv should be doing the actual "dirty work", with putenv
being a wrapper. This would save some cycles (and, possibly, syscalls
-- from malloc), but, of course, it would not be very significant with
todays hardware, yada, yada...
Would you have any other comments about my original post -- why is
pam_setenv causing the segfault somewhere, and is there anything wrong
with my patch? Thanks!
-mi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
