Date: Tue, 9 Jun 1998 16:33:10 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, imp@village.org Cc: cvs-all@FreeBSD.ORG, cvs-bin@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/bin/cp utils.c src/bin/csh dir.c src/bin/pax ftree.c Message-ID: <199806090633.QAA05878@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>: Actually, readlink() never NUL-terminates, but some buggy applications >: add their own NUL at the end of the path. Most applications use a buffer >: of size PATH_MAX, so it's not clear if there are any problems in practice. I should have said that all applications (except very buggy ones :-) add the NUL, and some buggy ones add it after the end of their buffer. >This patch fixes that. Also, most of the code that I recall seeing >uses MAXPATHLEN, but that is defined to be PATH_MAX on FreeBSD, so you >are correct. The man page states that when the length of the name >exceeds PATH_MAX, it will return an error, but is silent on what >happens if the path length is exactly equal to PATH_MAX. Most of the code is crufty. PATH_MAX is POSIX standard, and POSIX has been Standard for almost 10 years now. It's fairly clear that MAXPATHLEN includes space for the terminating NUL (see intro.2). Most of man pages are too localised to BSD and give the limit as 1023 (PATH_MAX - 1). However, PATH_MAX seems to be irrelevant for path returned by readlink(). I think the kernel should return any name it can fit, and longer names can be generated on foreign systems. >You are right that this likely isn't a problem or an exploitable hole, >but a little prevention doesn't hurt, no? It hurts to complicate the code for no reason. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806090633.QAA05878>