Subject: Re: need for end*ent()?
To: John Nemeth <>
From: Steven M. Bellovin <>
List: tech-security
Date: 09/14/2005 04:15:31
In message <>, John Nemeth write
>On Feb 3, 10:26pm, "Steven M. Bellovin" wrote:
>} In message <>, John Nemeth wr
>} >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 descript
>} >} >     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.
>     getpwent_r() isn't called by the library, just getgrnam() and
>getpwnam_r() (it will be getgrnam_r() when I'm done).

I know that getpwent_r() isn't called; that's the ambiguity in the man 
page that I'm talking about: it doesn't say what happens to the pointer 
if getpwnam_r() is called.  I quoted the text about getpwent_r() to 
show that one of the related functions would cause trouble.  Sorry I 
didn't make that clear.

		--Steven M. Bellovin,