Chris Turner wrote: > > Wondering if anyone had a chance to take a look at these - > Subject line tagged accordingly :D
> > I could see in some scenarios, aside from generating incorrect > > data, this incorrect record could be used to facillitate hiding > > presence of a successful compromise. > > > > The attached patch calls fsync(2) on related FD's in the login(3) > > routines, which corrected the problem on my test machine, > > and imho might be a good idea in general. AFAIK it should not be necessary to call fsync() before close(). Closing a file should flush all its data. The patch either does nothing, or masks a much more serious somewhere else. (The latter is a distinct possibility, but we can't go adding fsync to hundreds of file operations throughout the tree.)
