[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [address@hidden: Re: serious bug. Evolution and Microsoft mentality.
From: |
Marcus Brinkmann |
Subject: |
Re: [address@hidden: Re: serious bug. Evolution and Microsoft mentality.] |
Date: |
Fri, 11 Jan 2002 22:57:34 +0100 |
User-agent: |
Mutt/1.3.25i |
On Fri, Jan 11, 2002 at 10:21:17PM +0100, Jeroen Dekkers wrote:
> On Fri, Jan 11, 2002 at 03:20:20AM +0000, Adam Olsen wrote:
> > The basic question is whether realpath() uses _POSIX_PATH_MAX as the
> > limit, which is a useful behavior (atleast as far as realpath goes),
> > or whether it uses no limit at all, which is as useless as gets().
> >
> > As for portability, I think the best is to use canonicalize_file_name
> > when it's available, and fallback to realpath if it's not. Otherwise,
> > although your program would compile, it'd be broken if you ever got a
> > path that was too long (either by crashing or getting the file wrong).
> > And don't say it won't happen. The hurd is *alot* more flexible than
> > traditional systems, so it's more than possible somebody could dream
> > up a use for it in the future.
>
> I read the austin draft 7. The with realpath() generated pathname is
> stored as a nul-terminated string, up to PATH_MAX bytes. If PATH_MAX
> doesn't exist, there is just no limit. You never know how big the
> returned string and realpath() would just cause a buffer
> overflow. _POSIX_PATH_MAX has nothing to do with it, it just specifies
> a minimum for PATH_MAX, a system may not define a lower value.
Note that our current glibc implementation (stdlib/canonicalize.c) will
hardcode a fixed max size of 1024 for the string returned by realpath if
PATH_MAX and pathconf don't indicate a limit.
Yes, if you define your own PATH_MAX in your application, and use 512 (or
anything smaller than 1024), you have a potential buffer overflow for each
realpath() invocation if your program runs on the Hurd.
Obviously, realpath() behaviour on non-PATH_MAX systems is not specified.
Looks like a bug in POSIX to me.
On the GNU system, using canonicalize_file_name is the way to go. All other
systems I know are safe because they define PATH_MAX.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de