realpath() will dereference all symlinks and resolve
references to /./ and /../ (and so on). realpath
accepts a source buffer and a destination buffer to
copy the resolved path into. On certain systems
PATH_MAX can be of arbitrary size, while the buffer
passed in would be of a limiited size.

There is no way to specify how long your "resolved"
buffer is, therefore it is possible for one to overflow it.

According to the man page:

BUGS
Never use this function. It is broken by
design since it is impossible
to determine a suitable size for the output
buffer. According to POSIX
a buffer of size PATH_MAX suffices, but
PATH_MAX need not be a defined
constant, and may have to be obtained using
pathconf(). And asking
pathconf() does not really help, since on the
one hand POSIX warns that
the result of pathconf() may be huge and
unsuitable for mallocing mem-
ory. And on the other hand pathconf() may
return -1 to signify that
PATH_MAX is not bounded.

glibc has certain extensions to avoid the buffer
overflow. One option is to use
canonicalize_file_name(), another is to specify a NULL
as the second argument to realpath() (which essentially
makes it behave like canonicalize_file_name(). Relevant
documentation:

info libc
http://www.delorie.com/gnu/docs/glibc/libc_279.html

Attached is a patch to use canonicalize_file_name if
available.

Logged In: YES
user_id=631694

there are two bugs in the patch: one is explained on
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169046
the other one is that with this patch, the value of n
(length to be copied) stays zero all the time, so no copy
occurs and various things happen.

i have a patch, but don't know how to attach it - should i
mail it to you?

Logged In: YES
user_id=27350

There are actually a few more, very subtle problems with the
new patch as well. I'll get misa to update a patch once
I've worked through them.

In general, regarding Red Hat's bz# 169046, there's no
reason to do readlink() or realpath() if you've got
canonicalize_file_name; it should provide both sets of
functionality just fine.

Logged In: YES
user_id=27350

... but I see you meant the condition different than I
parsed your explanation. Anyway, I'll get misa to upload a
new patch once I've figured out what's going wrong entirely.

Logged In: YES
user_id=631694

if I may kindly remind you that this is a good time to
implement some kind of a patch ;e) now that python 2.5 is
nearing completion, and there's even a security advisory
(http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-1542)...

I have a working patch, applicable against 2.5c1, at
http://users.suse.cz/~jmatejek/python-2.4.2-canonicalize2.patch
(note the version number - the affected function didn't
change since 2.4.2)

See http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-1542

The patch introduces a memory leak, canonicalize_file_name() returns a
new allocated string which is not freed later.

Disclaimer: this bug is more than 3 years old, I don't remember all the
details.

Victor, solely reading the patch I see:

+#ifdef HAVE_CANONICALIZE_FILE_NAME
+ free(argv0);
+#endif /* HAVE_CANONICALIZE_FILE_NAME */

so argv0 (the string where the results of canonicalize_file_name() is
stored) should be freed.

Is there another branch that does not hit this code, that would create
the memory leak?

Surely this security issue should be addressed?

The latest POSIX versions (*) allow NULL to be passed for the target memory area, meaning that realpath() will allocate as much memory as necessary by itself. This essentially does the same thing as canonicalize_file_name(), but in a standard way rather than by relying on a GNU extension.

I suppose that possibility could be checked at configure time.

(*) http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html

It's a real shame the original patch was not applied before py3k was branched, the code is now different.

Antoine, my autoconf knowledge is limited, I don't know how you'd test for realpath accepting a NULL argument (and doing the right thing) at compile time.

My involvement with this bug is fairly limited at this point, I would like to see it fixed, but having seen no movement on it for almost 6 years now, maybe it's not as critical as I thought it was.

See issue bpo-12801: it has a more recent patch.

Victor, bpo-12801 was closed. What about this ticket?

We do still use realpath(3), now inside the _Py_wrealpath function in fileutils.c, so I think the original issue still applies.