In message <200509140707.j8E77lfP011272@vtn1.victoria.tc.ca>, John Nemeth write
s:
>On Dec 30,  7:52pm, Hubert Feyrer wrote:
>} On Tue, 13 Sep 2005, John Nemeth wrote:
>} >     I am working on libwrap to remove a reference to getgrnam().
>} > Immediately after the use of getgrnam(), it calls endgrent() (there is
>} > also a call to endpwent()).  I'm considering removing these in order to
>} > reduce possible side effects on applications using the library.
>} > However, I'm wondering if they should be left to ensure database
>} > updates are seen in long running daemons as per this paragraph in the
>} > manpage:
>} >
>} >     It is dangerous for long-running programs to keep the file descriptors
>} >     open as the database will become out of date if it is updated while th
>e
>} >     program is running.
>} >
>} > Does anybody else have any thoughts on this issue?
>} 
>} The calls exist and are being used (properly) for the stated reason.
>} Why would you want to remove them?
>
>     Because if the application happens to iterating a database by
>using getgrent() or getpwent() at the time it makes a call to libwrap I
>wouldn't want its pointer to be reset.  I have no idea why an
>application would do this.  However, I don't think it is up to me or
>necessarily up to any particular library to make this choice for it.
>
If that's the case, you're already in trouble, I think -- won't 
getpwnam_r() reset the pointer?  The man page doesn't say (and I 
haven't looked at the code because I'm trying to assess expected 
behavior), but it does say 

     Calling getpwent_r() from multiple threads will result in
     each thread reading a disjoint portion of the password database.

(Hmm -- what does Posix say?)

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb