Re: Fix allocation limit for getcwd syscall

[Andreas Schwab <schwab at suse dot de>]

Roland McGrath <roland@redhat.com> writes:

>> PATH_MAX only limits the length you can pass to functions taking a file
>> name.  It does _not_ limit the length of absolute names of files in the
>> system.  The coreutils testsuite explicitly tests for the ability to
>> determine the name of the cwd when it exceeds PATH_MAX.
>
> I understand the reality of what getcwd can produce, and the implementation
> reasons why it is difficult to constrain the length of a directory name
> that can exist.  However, your statement is not an accurate
> characterization of what POSIX says.  It says "absolute pathname" in the
> specification of getcwd.  In 3.266 it defines the term "pathname", and
> says, "... a pathname consists of, at most, {PATH_MAX} bytes, including the
> terminating null byte."

A pathname can also be a relative pathname, which can result in an
absolute filename that is longer than PATH_MAX if you combine this
pathname with cwd.  You won't be able to pass this combined pathname to
chdir, but you still can do it in two steps, and nothing forbids this
being sucessful.

But this is besides the point: POSIX does not say anything about syscalls.
The fact is that the Linux getcwd syscall can return file names that are
as big as PAGE_SIZE, and the getcwd implementation has to cope.

>> > That said, I don't think the code should presume what the kernel
>> > implementation does in this regard.  It should do something other than
>> > crash when it gets ERANGE.
>> 
>> PAGE_MAX has always been the limit that the kernel imposes on getcwd.  It
>> was wrong to use PATH_MAX in the first place.
>
> This statement has no bearing on my point.

It is the very source of the bug.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."