Re: CVS commit: src/usr.bin/login

[christos%zoulas.com@localhost (Christos Zoulas)]

On Sep 27,  2:07pm, jnemeth%victoria.tc.ca@localhost (John Nemeth) wrote:
-- Subject: Re: CVS commit: src/usr.bin/login

| On Feb 11,  4:43am, Jason Thorpe wrote:
| } On Sep 21, 2005, at 9:48 AM, Christos Zoulas wrote:
| } > On Sep 21,  9:19am, thorpej%shagadelic.org@localhost (Jason Thorpe) wrote:
| } >
| } > | > Modified Files:
| } > | >       src/usr.bin/login: login_pam.c
| } > | >
| } > | > Log Message:
| } > | > use getgrnam_r; from Jon Nemeth
| } > |
| } > | Just curious -- what is the point / benefit of using _r in single-
| } > | threaded apps?  Sure, in libraries it makes perfect sense... but in
| } > | login(1)?
| } >
| } > Consistency?
| } 
| } IMO, it's gratuitous change.
| 
|      All applications that use PAM were converted.  This is in case a
| PAM module uses get{gr,pw}* functions without using the _r functions.
| I noticed that FreeBSD did this with rexecd for this reason.  I posted
| about it on our mailling lists.  I don't recall who in the NetBSD camp
| decided to do the same thing and started converting apps.  It wasn't
| me, I just finished it.
| 
|      Note that all PAM modules supplied with NetBSD have been converted
| to using the _r functions so that they don't affect applications using
| them.  However, the PAM using applications were still converted to
| using _r functions, just in case a third party PAM module isn't as
| cautious.

Actually I will be less flippant about it and I will answer this properly.
It has nothing to do with being `single-threaded' vs. `multi-threaded'. It
has to do with the fact that if you call in your code:

        gr = getgrnam("thorpej");

then you call pam, a pam module can call internally:

        gr1 = getgrnam("drevil");

Finally, when you try to use "gr" again in your code, you get drevil's data.
It is always better to be conservative and use the re-entrant (non-static
data sharing) routines, even if that requires more work on the application
programmer's part. People copy snippets of code all the time from one
program to another, without understanding clearly that what is safe in one
context, might not be safe in another. Better be safe than sorry. By always
using the _r flavor of the routines, you don't have to worry about calling
into a shared library that can modify libc's state.

christos