[Top][All Lists]
[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