KPasswordEdit patch (was Re: new widgets...)

[Malte Starostik]

On Sunday 29 September 2002 01:54, Guillaume Laurent wrote:
> On Saturday 28 September 2002 22:49, Malte Starostik wrote:
> > On Friday 27 September 2002 10:50, Neil Stevens wrote:
> > > Grr.. that's not what I meant to convey.  I agree the mlock is
> > > worthless. I think the const char * is just as worthless.
> > >
> > > I'm talking about making optional the use of a clunky, inconvenient
> > > const char *, when a QString is no less safe for nearly all of KDE's
> > > users.
> >
> > Having used the STL excessively in the past few weeks I have to say the
> > real fix would be to extend QString so that one can use a custom
> > allocator like with std::string. Then this custom allocator could care
> > for wiping the memory used for the password without losing the power of
> > QString...
>
> I'm not sure I understand this need for wiping the password. Suppose you
> don't wipe it and it gets somehow written on disk, either through a core
> dump, or on the swap. Then what ? If a bad guy has access to the core file,
> he has access to your files, so you're screwed. If a bad guy has access to
> the swap, then he's root, so you've totally screwed.
It's not only about writing it to swap/disk (that was what the mlock patch 
would do, but only for root). Think about a multi-user system with an OS that 
doesn't guarantee memory is zeroed-out. User a enters a password and the 
process that provided the password edit exits. User b was monitoring this and 
allocs huge amounts of memory, in the hope he gets the physical memory user a 
had before. If he succeeds, he can read the password. Granted, it takes some 
luck but it's possible.

-Malte