On Fri, 18 Oct 1996, [KOI8-R] wrote:
> > >
> > > bzero'ing a hash buffer is not a complete solution to the problem,
> > > since the process may contain other potentially sensitive data
> > > in its address space. What you really want to do is protect
> > > the cores.
> > >
> I consider it as a bad move too and performance degradation.
> Why only DB? Why you don't automatically clear stack too? :-)
> Passwords can be stored anywhere in the application,
> and it is per-application task to clear sensetive data anywhere.
Is there an efficient way for a process to clear all memory that was
allocated and deallocated by any function that it has called but not, of
course, memory it is still using? The issue came up from ftpd calling
getpwnam that calls some DB routines. The DB routines allocate and
deallocte the memory internally, so getpwnam does not know what memory DB
I guess that in -current it doesn't matter since the process won't core
dump anyway since it has done a setuid(). As long as there is no way
other than core dumps or attaching with ptrace for a user to get
information from the memory space of a program running as their uid that
was running as root, this isn't a problem in -current. However, I'm not
sure I want to trust that idea. Is reading of /proc/<pid>/mem disabled if
a program has done a setuid()?