Date: Wed, 5 May 1999 14:17:51 +1000 From: Bruce Evans <bde@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 Message-ID: <199905050417.OAA04953@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905050417.OAA04953>