Bugtraq mailing list archives
Re: strcpy versus strncpy
From: nmm1 () CUS CAM AC UK (Nick Maclaren)
Date: Thu, 5 Mar 1998 17:49:24 +0000
"file name" can mean (at least) two things: a directory entry (ie, a single link in the filesystem tree) or an entire path name.
Yes. In the context of buffer overflow, the latter is more usually relevant (as well as conforming to more traditional use).
The former has always had a hard limit and likely always will. This limit used to be (IIRC) 14 bytes under V7 and older SysV; FFS raised this to 255. I have never seen it higher than 256; if you know of a UNIX-alike with this limit higher than 255 I would love to hear full details.
Sigh. That isn't the point. Many or most of the 14 character Unices allowed longer names, and truncated them quietly to fit, which is why POSIX explicitly allows that behaviour. I do not know if any 255 character Unices do, but I would expect so. Furthermore, think of a tar file created on a non-Unix system for unpicking on a Unix one, or what compress may do on a file with a 255-character name. A robust program has to allow for longer names being supplied to it, even if it can assume that it will not find them in a directory entry.
The documentation for 4.3 claimed there was a hard limit MAXPATHLEN on the total length of a pathname - AFAICR I never verified this. But I just looked at the NetBSD source and it (and by implication, probably 4.4 and almost all derivatives thereof) imposes a similar hard maximum, again MAXPATHLEN (though I don't know whether the value differs between 4.3 and 4.4/NetBSD/etc). ...
How? Try creating a filing system with a 1000 character path name in it and mounting it in a directory with a 1000 character path name in another filing system. Are you seriously saying that the mount WILL fail? And, actually, you used to be able to do this simply by creating subdirectories under most Unices, though I haven't tried recently. And then think of symbolic links and what they imply ....
I also note the presence of _PC_PATH_MAX and _PC_NAME_MAX in the pathconf() manpage. The manpage claims POSIX compliance, and I thus have reason to think POSIX defines those, though I do not have a copy of POSIX handy to check. But there is a strong implication that POSIX expects such limits to exist (otherwise, why provide a way to query them?), and if you can demonstrate the existence of anything even vaguely UNIXish that does not impose hard and relatively small limits on path and name length I would love to hear about it.
I do, and I suggest that you look it up (and then run some experiments). pathconf() is required to return a value no lower than _PC_PATH_MAX, and may fail (which often happens for remote filing systems). Furthermore, POSIX explicitly permits _PC_PATH_MAX not to be defined and pathconf() to return -1 if the limits are essentially infinite (whatever that may mean). I don't know of any Unices that do this, but there may well be some.
PATH_MAX (and friends) under Unix is a lower bound on the length of a name that the system is required to support under all circumstances.What is your authority for this statement? The only documentation I have found on what PATH_MAX is is the comment in <sys/syslimits.h>, which says simply "max bytes in pathname".
POSIX.1 (1990).
But there are facilities that work with any length of name that they are supplied with.Please give an example. (The example must, of course, use the string as a pathname; calls such a strcpy() that manipulate strings without treating them as pathnames are irrelevant here.)
Anything that takes an argument and recurses down the path using chdir() rather than simply opening the pathname. And even opening the pathname MAY work on some Unices, as passing an overlong name to open() is not actually REQUIRED to fail. Nick Maclaren, University of Cambridge Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB2 3QG, England. Email: nmm1 () cam ac uk Tel.: +44 1223 334761 Fax: +44 1223 334679
Current thread:
- Re: strcpy versus strncpy, (continued)
- Re: strcpy versus strncpy Andy Church (Mar 02)
- Re: strcpy versus strncpy Edwin Li-Kai Liu (Mar 03)
- Re: strcpy versus strncpy Ben Laurie (Mar 03)
- Re: strcpy versus strncpy Chris L. Mason (Mar 03)
- Re: strcpy versus strncpy der Mouse (Mar 04)
- Re: strcpy versus strncpy Aleph One (Mar 04)
- Re: strcpy versus strncpy Aleph One (Mar 04)
- Re: strcpy versus strncpy Aleph One (Mar 04)
- Re: strcpy versus strncpy Aleph One (Mar 04)
- Re: strcpy versus strncpy der Mouse (Mar 05)
- Re: strcpy versus strncpy Nick Maclaren (Mar 05)
- Re: strcpy versus strncpy Steve Bellovin (Mar 05)
- Re: strcpy versus strncpy Paul McNabb (Mar 05)