realpath() security issue, potential fix

Michael Pyne pynm0001 at
Mon Aug 9 21:42:03 BST 2004

Hash: SHA1

On Monday 09 August 2004 15:21, David Faure wrote:
> > Unfortunately,
> > they don't recommend an alternative function to use either, and after
> > quite a bit of Googling, I wasn't able to find a suggested alternative
> > online.  One site seemed to suggest that if the input path was less than
> > MAX_PATH characters long that realpath was safe, but that seemed to be
> > against the general consensus.
> Common sense would indicate that it's the _output_ path that has to be
> allocated to MAX_PATH characters....

Every source of information on realpath() indicated that output had to at 
least be MAX_PATH long, but apparently some implementations of realpath() 
will also overflow if input length is > MAX_PATH.  And the problem is that 
you can't trust MAX_PATH sometimes, since it's simply a #define.

Say you upgrade your kernel to one with a larger MAX_PATH, now you've got a 
buffer overflow again until you recompile.  There are POSIX functions to get 
MAX_PATH at runtime, but apparently they're allowed to return "no set 
length", which is next to useless. :-(

> > I know of at least one KDE application that uses realpath(3)
> Actually they all do, via KStandardDirs.

Oh, I didn't know that.  Perhaps that makes it that much more useful.

> Anyway.... doesn't QDir::canonicalPath() do this already?

QDir::canonicalPath() does do this, but from reading the source, they call 
realpath() also, at least when I checked while writing this replacement.

> > P.S. I tried attaching the file last time I e-mailed -core-devel, but
> > KMail turned the whole message into an attachment an the message got
> > dropped.
> You put the mail in the drafts folder temporarily, right? I had that bug
> too, but I couldn't reproduce it :(

Actually I didn't, but I couldn't reproduce it either, so I'm not sure what's 
going on.  I don't know if you've already read my other e-mail, but I've 
revised the patch.  I also just now changed the license, it's pretty silly to 
propose GPL'ed code for inclusion in kdelibs.  The license is now LGPL.

It's still up at

 - Michael Pyne
Version: GnuPG v1.2.4 (GNU/Linux)


More information about the kde-core-devel mailing list