From: Soeren D. S. <soe...@gm...> - 2005-10-15 13:49:30
|
Hello, I have (hopefully) successfully ported CLisp to GNU/Hurd. However, there was the issue that GNU/Hurd does not define MAXPATHLEN. This is not a bug in GNU/Hurd, as POSIX does not require MAXPATHLEN and neither do the GNU Coding Standards. For major parts of the code, the existence of MAXPATHLEN is asserted by an #ifndef clause. The only exception is src/execname.c, and I have decided to fix it according to the GNU Coding Standards, which means that MAXPATHLEN is not used at all, or at least not if not defined natively. Could you review the patch below? Sören PS: I am not subscribed, so please CC me. --- clisp-2.35.orig/src/execname.c +++ clisp-2.35/src/execname.c @@ -125,12 +125,22 @@ /* exec treats paths containing slashes as relative to the current directory */ if (maybe_executable(program_name)) { + char *new_exec_name; + resolve: /* resolve program_name: */ +# ifdef MAXPATHLEN executable_name = (char*) malloc(MAXPATHLEN); if (executable_name == NULL) { errno = ENOMEM; goto notfound; } - if (realpath(program_name,executable_name) == NULL) { - free(executable_name); goto notfound; +# else + executable_name = NULL; +# endif + new_exec_name = realpath(program_name,executable_name); + if (new_exec_name == NULL) { + free(executable_name); + goto notfound; + } else { + executable_name = new_exec_name; } return 0; } |
From: Sam S. <sd...@gn...> - 2005-10-16 02:16:53
|
> * Soeren D. Schulze <fbrera.q.fpuhymr@tzk.qr> [2005-10-15 15:49:14 +0200]: > > there was the issue that GNU/Hurd does not define MAXPATHLEN. > > This is not a bug in GNU/Hurd, as POSIX does not require MAXPATHLEN and > neither do the GNU Coding Standards. For major parts of the code, the > existence of MAXPATHLEN is asserted by an #ifndef clause. thanks. what is the difference between MAXPATHLEN and MAX_PATH? (and what is the latter's value on hurd?) -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.savegushkatif.org> <http://www.palestinefacts.org/> <http://ffii.org/> <http://pmw.org.il/> <http://www.openvotingconsortium.org/> There are 3 kinds of people: those who can count and those who cannot. |
From: Soeren D. S. <soe...@gm...> - 2005-10-16 13:41:51
|
Sam Steingold schrieb: >>* Soeren D. Schulze <fbrera.q.fpuhymr@tzk.qr> [2005-10-15 15:49:14 +0200]: >> >>there was the issue that GNU/Hurd does not define MAXPATHLEN. >> >>This is not a bug in GNU/Hurd, as POSIX does not require MAXPATHLEN and >>neither do the GNU Coding Standards. For major parts of the code, the >>existence of MAXPATHLEN is asserted by an #ifndef clause. > > > thanks. > what is the difference between MAXPATHLEN and MAX_PATH? > (and what is the latter's value on hurd?) I don't know about the difference. I assume it is equivalent. GNU libc's realpath uses PATH_MAX, at least, if defined by the system, they say in the documentation. GNU philosophy is, however, that there should be no limits at all. So under GNU/Hurd, neither MAXPATHLEN nor MAX_PATH are defined. Right now this makes me ponder about other uses of MAXPATHLEN in CLisp because CLisp defines MAXPATHLEN itself in the .d files. The point is that if you define MAXPATHLEN yourself but realpath thinks there are no limits, couldn't this cause a buffer overflow? I will have to check where MAXPATHLEN is also used and if there are functions that behave differently if MAXPATHLEN is undefined on the system -- like realpath. Another problem is that my patch does an assumption: that if MAXPATHLEN is undefined, realpath supports being called with NULL. This is the case for all the systems I know (GNU/Hurd being the only system that does not define MAXPATHLEN), but if one tries to compile it on a system that does not fit this assumption, it will create a subtle runtime error. In any case, beware removing the "# ifdef MAXPATHLEN" case. This would introduce a build error for all systems that do not support realpath being called with NULL. Nevertheless, if you have reviewed the patch and you think it works, it is probably safe to apply it as it will not affect other systems being currently supported. Sören |
From: Sam S. <sd...@gn...> - 2005-10-20 00:56:13
|
I took a different path - in line with existing code in unix.d thanks for reporting the bug. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.jihadwatch.org/> <http://www.mideasttruth.com/> <http://ffii.org/> <http://pmw.org.il/> <http://www.openvotingconsortium.org/> You can have it good, soon or cheap. Pick two... |
From: Soeren D. S. <soe...@gm...> - 2005-12-14 14:37:50
|
Sam Steingold schrieb: > I took a different path - in line with existing code in unix.d > thanks for reporting the bug. Sorry for replying so late... I think your path introduces a security issue: realpath does not notice that MAXPATHLEN is defined in the code; it still assumes that it acts on a system without any limits. So if the path is longer than MAXPATHLEN, a buffer overflow might occur. However, I will check other uses of MAXPATHLEN and try to fix them in compliance to the GNU coding standards, which definitely prohibit artificial limitations. The definition of MAXPATHLEN in unix.d might introduce yet other security issues. Those fixes will not touch the existing code a non-trivial way, as MAXPATHLEN is a system limitation and it is safe to work with if it is actually imposed by the system. GNU libc provides features that work without artificial limits conveniently (as realpath() accepting NULL as I used in my patch). I am, however, unsure about other other systems that might not define MAXPATHLEN but work a different way here. Perhaps individual configure checks are the right way to examine this, even though I am not aware of any platform that might cause problems. Defining MAXPATHLEN on one's own is probably never a clean fix. It is even a bit dangerous because it hides the problems instead of fixing them. I will send you the patch when it is done. Sören |