qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Use of PATH_MAX


From: Warner Losh
Subject: Re: [Qemu-devel] Use of PATH_MAX
Date: Fri, 16 May 2008 08:09:40 -0600 (MDT)

From: Anthony Liguori <address@hidden>
Subject: Re: [Qemu-devel] Use of PATH_MAX
Date: Fri, 16 May 2008 09:00:39 -0500

> Ian Jackson wrote:
> > There are a couple of places where we use PATH_MAX.  I don't think
> > this is right.  PATH_MAX is a #define specified by POSIX, SuSv3 etc.
> > But it isn't guaranteed to be defined or necessarily very useful.
> >
> > In particular, it may be defined to a very large value (larger than a
> > practical static buffer).  Or on systems where the maximum pathname
> > length varies (for example, it depends on the underlying filesystem)
> > it may be not defined at all and applications which really need to
> > know are supposed to use pathconf.
> >
> > I think it would be better to invent a new name for the maximum path
> > length supported by qemu's statically-sized buffers.  This would
> > replace both the uses of PATH_MAX (in block.c, linux-user/path.c, and
> > block-vvfat.c) but also direct use of (eg) 1024 in many places.
> >   
> 
> It would be far better to get rid of instances of PATH_MAX and replace 
> them with dynamically allocated buffers.   The use of static sized 
> buffers for filenames is just asking for subtle bugs (and possibly even 
> security problems.

As is the use of dynamic buffers.  If you don't always test system
call return value, you can get odd new failures.  If you don't provide
a sane upper bound, then you get DoS attacks...

Warner




reply via email to

[Prev in Thread] Current Thread [Next in Thread]