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 #12801: it has a more recent patch.

Victor, #12801 was closed. What about this ticket?