From owner-freebsd-bugs  Tue May  4 21:18:20 1999
Delivered-To: freebsd-bugs@freebsd.org
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9])
	by hub.freebsd.org (Postfix) with ESMTP id 7E64815863
	for <freebsd-bugs@FreeBSD.ORG>; Tue,  4 May 1999 21:17:54 -0700 (PDT)
	(envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id OAA04953;
	Wed, 5 May 1999 14:17:51 +1000
Date: Wed, 5 May 1999 14:17:51 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199905050417.OAA04953@godzilla.zeta.org.au>
To: freebsd-bugs@FreeBSD.ORG, venglin@lagoon.freebsd.org.pl
Subject: Re: i386/11454: mkdir() and chdir() doesn't check argument lengt
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> >  chdir() and mkdir() work correctly.  They can't reasonably check the
> >  length of the path to the current directory, and POSIX.1 doesn't
> >  permit them to fail because the current directory is deep.
> 
> Ok, but mkdir() and chdir() manual tells:
> 
> ERRORS
>      Mkdir() (chdir()) will fail and no directory will be created if:
> [...]
>      [ENAMETOOLONG]
>                  A component of a pathname exceeded 255 characters, or
>                  an en- tire path name exceeded 1023 characters.
> 
> But it doesn't fail. 

The limits are for the pathname which is passed to mkdir() and chdir().
Similarly for most syscalls that take a pathname arg.  mount() is the
most interesting.  Take a perfectly valid filesystem with no pathnames
longer than 1023, but one of length 1020, and mount it on /usr.  Then
you have a pathname of length 1024.  Is mount() supposed to examine
all pathnames under the mount point and fail if a combined pathname
would be too long?  No.

> >  The bugs are in the system commands.  In particular, POSIX.2 specifies
> >  that `find' and `rm -r' shall work for arbitarily deep directories
> >  (provided directory names longer than PATH_MAX aren't specified on the
> >  command line), and that `ls -R' should handle arbitrarily deep directories
> >  (it shouldn't fail unless it runs out of memory for keeping track of
> >  untraversed directories).
> 
> So theoretically I can create directory, on which _all_ system 
> commands will fail, because they doesn't have enough of memory?

Only badly written ones will fail.  To handle arbitary depths, it is
necessary to use lots of chdir()s.  Only about PATH_MAX bytes of memory
needs to be used.  ".." must be relied on because the full path to the
parent directory might be too long.

> >  `find' seems to traverse deep directories correctly.  However, the
> >  following don't work:
> >  1) passing long names found by `find' to other utilities.
> 
> Overflow occurs, when find tries to print out a long pathname by 
> invoking puts(). So, I think (but I'm not sure) that it could be 
> dangerous and should be fixed...

I don't see any problems there.  fts returns very long pathnames and
puts() has no problems printing strings of any length, but everything
has problems handling long pathnames.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message