[MPlayer-dev-eng] [PATCH] fix for unconditional use of PATH_MAX

[Robert Millan]

On Mon, Apr 28, 2003 at 07:49:32PM +0200, Fabian Franz wrote:
> 
> I'm against this patch.
> 
> We had this code before and decided to drop it in favor of PATH_MAX (as 
> someone said it was POSIX). To now have it as optional and to make this small 
> code so much more complicated is IMHO nonsense.
> 
> If you need it, the right fix would imho be to do:
> 
> #ifndef PATH_MAX
> #define PATH_MAX	SOME_HIGH_VALUE // for example 512, if gnu/hurd can handle 
> that, dunno atm.
> #endif

POSIX describes PATH_MAX, but it is left optional to implementors wether
it is defined or not.(I can search you the exact quote if you need it)

If it isn't defined, it means there's no imposed limit in the length
a path can have, and your code needs to be prepared to handle any
path length, no matter how long it is.

Defining a hard-coded value is not a solution, not only because it
imposes a limitation we don't have (we can live with that), but is
also introducing a buffer overflow vulnerabilty.

consider the following call in mplayer.c:

char cwd[PATH_MAX+2]
[...]
getcwd(cwd, PATH_MAX)

If you hardcode PATH_MAX to, say 512, you'd be declaring a 512-byte
buffer and telling getcwd to write the current path to it. If the
current path is longer than 512, we're dead. mplayer would crash on
directories longer then 512 bytes, a malicious user could create a
directory longer than 512 bytes and put exploit code in the directory
name, etc.

-- 
Robert Millan

make: *** No rule to make target `war'.  Stop.

Another world is possible - Just say no to genocide