|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #29937 $_FILES['name'] no longer has full path (from 4.3.4 to 4.3.8)
Submitted: 2004-09-01 22:40 UTC Modified: 2004-11-15 16:29 UTC
Avg. Score:4.3 ± 0.9
Reproduced:16 of 17 (94.1%)
Same Version:7 (43.8%)
Same OS:7 (43.8%)
From: justin at timelesstech dot com Assigned:
Status: Wont fix Package: *Directory/Filesystem functions
PHP Version: 4.3.8 OS: FreeBSD 4.8 stable
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
34 + 38 = ?
Subscribe to this entry?

 [2004-09-01 22:40 UTC] justin at timelesstech dot com
We have had scripts running for a while now fine on PHP 4.3.4 that assume that the $_FILES['name'] value on file uploads contains the full /path/to/the/filename.txt

However after our server admins upgraded to PHP 4.3.8 the $FILES['name'] now only contains the filename, with no path. This makes it impossible for our recursive file uploader script to work, since it NEEDS the pathname of those files to know what directory/subdir on the server to upload the file(s) to!

The changelog does not mention this, but does anybody have any ideas?


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-09-02 08:20 UTC]
Did you compile PHP from source or did you use the ports? If you used the ports, can you check what patches were applied to the clean php source?
 [2004-09-02 08:40 UTC] justin at timelesstech dot com
Our web host, pair Networks, installed the PHP version to the server. I believe they compiled from source, and I know they are experts at installing and configuring PHP as they manage hundreds of servers.

From a phpinfo() command here are the configure command options they used on Aug 18/04:

'./configure' '--with-apache=/usr/pair/sw/apache_1.3.29' '--with-config-file-path=/usr/local/etc' '--enable-magic-quotes' '--enable-bcmath' '--without-cdb' '--with-zlib-dir=/usr/local' '--with-gd' '--with-ttf' '--without-msql' '--with-mysql=/usr/local' '--with-iodbc' '--with-pdflib' '--enable-inline-optimization' '--disable-memory-limit' '--with-db' '--without-gdbm' '--with-ndbm' '--without-db2' '--without-dbm' '--with-gettext' '--without-readline' '--with-recode' '--without-openssl' '--with-mcrypt' '--without-db3' '--enable-dba' '--with-curl' '--with-png-dir=/usr/local/lib' '--with-jpeg-dir=/usr/local/lib' '--enable-calendar' '--with-mhash' '--enable-xslt' '--with-xslt-sablot' '--with-expat-dir=/usr/local' '--enable-gd-lzw-gif' '--enable-mstring'
 [2004-09-03 14:56 UTC] brad at timelesstech dot com
It might have something to do with this bug fix:
 [2004-09-03 16:24 UTC] justin at timelesstech dot com
Yes it probably is related to that "fix" BUT this "fix" breaks a ton of code and changes the behavior. Can the "fix" be done in such a way that it prevents the security vulnerability, but doesn't break all the existing code out there that needs the client path of file(s) being uploaded?

Also before this new fix is fixed, is there any workaround?
 [2004-09-03 16:55 UTC]
Which path is this, of the original uploaded file name or the one on the server (in /tmp...)?
 [2004-09-03 16:58 UTC] justin at timelesstech dot com
It is the path of the original uploaded file name. The reason this info is needed, is when a bunch of files are uploaded via a web file manager application, it needs to know the path of each file, so when it re-creates the path/file structure on the server, it is able to put all the files in the right places, rather than everything going in "one directory".
 [2004-09-03 17:49 UTC]
I don't think the RFC actually allows that, nor was this ever documented. I will check the RFC later.
 [2004-09-03 18:46 UTC] justin at timelesstech dot com
It was not documented, but this has been the well-known behavior for quite some time, and the browsers do send the path information. Any code written to deal the the 'name' value has always had to deal with the path information, so changing it now breaks all code from previous versions. Perhaps the new behaviour default could be to only get the filename, but an override would allow us to get the path too? Just some way so that old written systems will still be able to work =)
 [2004-09-03 19:03 UTC] brad at timelesstech dot com
Let me clarify a bit...  we use a tool from Radinks, and in this tool there is a "FULL_PATH" option that will pass along the full path and filename in the $_FILES['..']['name'] variable.  By default, it's just the filename in this ['name'] variable, but Radinks did something (possibly in headers?) to allow the fullpath to come through.  It looks as though the security "fix" broke this desired behavoiur.
 [2004-11-15 16:29 UTC]
RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

15.5 Content-Disposition Issues

RFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) for details.

RFC 2388 "Returning Values from Forms:  multipart/form-data"

"multipart/form-data" contains a series of parts. Each part is expected to contain a content-disposition header [RFC 2183] where the disposition type is "form-data", and where the disposition contains an (additional) parameter of "name", where the value of that parameter is the original field name in the form. For example, a part might contain a header:

        Content-Disposition: form-data; name="user"

with the value corresponding to the entry of the "user" field.

Field names originally in non-ASCII character sets may be encoded within the value of the "name" parameter using the standard method described in RFC 2047.

RFC 2183 "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"

lists in 2.3:

The receiving MUA SHOULD NOT respect any directory path information that may seem to be present in the filename parameter.  The filename should be treated as a terminal component only.  Portable specification of directory paths might possibly be done in the future via a separate Content-Disposition parameter, but no provision is made for it in this draft.

So the current behavior is correct and advocated by the RFCs. PHP's handling of filenames will not be changed.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Jul 17 15:01:28 2024 UTC