Date: Sun, 17 Oct 1999 12:45:38 -0600 From: Warner Losh <imp@village.org> To: Marc Slemko <marcs@znep.com> Cc: hackers@FreeBSD.ORG Subject: Re: MAXPATHLEN not enforced Message-ID: <199910171845.MAA04645@harmony.village.org> In-Reply-To: Your message of "Sat, 16 Oct 1999 12:20:11 MDT." <Pine.BSF.4.10.9910161156420.13637-100000@alive.znep.com> References: <Pine.BSF.4.10.9910161156420.13637-100000@alive.znep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.10.9910161156420.13637-100000@alive.znep.com> Marc Slemko writes: : Why does FreeBSD let you create paths longer than MAXPATHLEN? Because this is allowed. : I often have various trees that are as deep as possible for testing various : programs for holes, and I finally figured out why locate wasn't updating its : database properly; it was choking as soon as it saw a path length : >MAXPATHLEN long. The question, however, is why can it see a path length : longer than MAXPATHLEN? MAXPATHLEN is the longest pathname that the kernel system calls can handle, but it isn't the longest pathname that can exist especially due to symbolic links. : I would also wonder if there aren't some security issues resulting : from this. From what gdb shows, locate seems to trash its stack : before spitting out the error about the path being too long... That is an error in the program in question. I do know that the shells on FreeBSD haven't been well audited for buffer overflows. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910171845.MAA04645>