Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110713140304.GE16618@brightrain.aerifal.cx>
Date: Wed, 13 Jul 2011 10:03:04 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: cluts review

On Wed, Jul 13, 2011 at 04:21:28PM +0400, Solar Designer wrote:
> > Instead of <sys/param.h> 
> > for PATH_MAX, will limits.h do (that's what i usually include)?
> 
> No, it doesn't get PATH_MAX defined for me.

Even with _POSIX_C_SOURCE=200809L? Did glibc really go and break that
too? :( The standard doesn't require it to be defined, but this is
just like their issue of removing PAGE_SIZE. All it does is create
more work and bloat for the application which has to go retrieve the
value via sysconf/pathconf. And if these still return "unlimited",
then many interfaces have *inherent* security bugs that cannot be
fixed due to writing out a string that's assumed to be able to
accommodate at least PATH_MAX bytes...

> What you could actually want to do is get rid of the dependency on
> PATH_MAX and FILENAME_MAX.  The system does not guarantee that actual
> pathnames fit in PATH_MAX anyway.  So you may want to replace those
> strcat()'s with dynamic memory allocation or add a check for potential
> buffer overflow there (then report the error and skip the test).

Indeed, I would use snprintf for this and just error out if the string
gets truncated, but you could also perform dynamic allocation.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.