Fix allocation limit for getcwd syscall

Fix allocation limit for getcwd syscall

[Andreas Schwab]

The actual filename limit of the getcwd syscall is PAGE_SIZE.  If we don't
allocate a buffer big enough we get an assertion failure when $PWD is
longer than PATH_MAX.

Andreas.

2005-11-04  Andreas Schwab  <schwab@suse.de>

	* sysdeps/unix/sysv/linux/getcwd.c (__getcwd): Increase default
	allocation size to one page.

--- sysdeps/unix/sysv/linux/getcwd.c.~1.22.~	2003-09-22 22:58:00.000000000 +0200
+++ sysdeps/unix/sysv/linux/getcwd.c	2005-10-01 23:41:53.000000000 +0200
@@ -86,7 +86,7 @@ __getcwd (char *buf, size_t size)
 	  return NULL;
 	}
 
-      alloc_size = PATH_MAX;
+      alloc_size = __getpagesize ();
     }
 
   if (buf == NULL)

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

Re: Fix allocation limit for getcwd syscall

[Roland McGrath]

We have bigger problems if PATH_MAX is defined but is not actually the
limit on the path name length as POSIX specifies.  If there is a larger
limit, that should be the PATH_MAX value.  If there is no limit, then
PATH_MAX should not be defined.

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.

Re: Fix allocation limit for getcwd syscall

[Andreas Schwab]

Roland McGrath <roland@redhat.com> writes:

> We have bigger problems if PATH_MAX is defined but is not actually the
> limit on the path name length as POSIX specifies.  If there is a larger
> limit, that should be the PATH_MAX value.  If there is no limit, then
> PATH_MAX should not be defined.

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.

> 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.

Andreas.

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

Re: Fix allocation limit for getcwd syscall

[Roland McGrath]

> 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."

> > 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.

Re: Fix allocation limit for getcwd syscall

[Andreas Schwab]

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."