[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cvs commit: src/bin/cp utils.c src/bin/csh dir.c src/bin/pax ftree.c
- To: bde@xxxxxxxxxxx, imp@xxxxxxxxxxx
- Subject: Re: cvs commit: src/bin/cp utils.c src/bin/csh dir.c src/bin/pax ftree.c
- From: Bruce Evans <bde@xxxxxxxxxxx>
- Date: Tue, 9 Jun 1998 16:33:10 +1000
- Cc: cvs-all@xxxxxxxxxxx, cvs-bin@xxxxxxxxxxx, cvs-committers@xxxxxxxxxxx
- Sender: owner-cvs-bin@xxxxxxxxxxx
>: 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.