Subject: Re: need for end*ent()?
To: Steven M. Bellovin <firstname.lastname@example.org>
From: John Nemeth <email@example.com>
Date: 09/14/2005 01:10:14
On Feb 3, 10:26pm, "Steven M. Bellovin" wrote:
} In message <200509140707.j8E77lfP011272@vtn1.victoria.tc.ca>, John Nemeth writes:
} >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
} >} > 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).
}-- End of excerpt from "Steven M. Bellovin"