When I try to upload a file using public method, I get the following:

http://domain.com/files/_0 bytes

When I change it to private method, I get the following:

system/files?file=_0 bytes

I've tried changing my file and tmp paths a million times, and have even chmoded the directories to 777, still nothing!

Sadly no errors in the logs. If anyone can help I would appreciate it as I'm going totally mad.

Thanks

Geoffrey

Comments

Anonymous’s picture

What drupal version are you using? I haven't update it to 4.5 or CVS HEAD yet so I dont think it will work on anything except 4.4.

djhomeless’s picture

Ahh,
I'm using 4.5.2. Any plans to update? I suppose I could try rolling back Drupal but I'm not sure what I would lose out on...

Sorry,

Geoffrey

shane birley’s picture

Having exact same issue on 4.5.2 with Private turned on.

http://drupal.org/node/12598

shane birley’s picture

Yes, the odd thing is that there is no error in the logs. Very strange.

shane birley’s picture

Title: Zero file when uploading with both public and private method » File=_0 Issue Problem Continued

I have been chatting with one of my hosts and I believe they are on to something. I did a comparison with several different hosts and their PHP setups and have noticed something: every host that has "safe-mode" off, the upload module and attachment module (which both appear to exhibit the same issue) work fine. But, if PHP has "safe-mode" turned on, the modules don't allow for file uploads. Here is what we has been discovered / investigated / looked at / etc:

Whether you have installed this application on other servers or not does not
have relevance to whether there are issues with Drupal. As mentioned
previously, Drupal appears to be using antiquated code to deal with file
uploads and should be updated (and from their forums, some modules appear to
have been already).

All of the sites you list do not have PHP's "safe_mode" enabled which is why
they work for Drupal install. Without "safe_mode" enabled PHP cares not
where a given file comes from as long as UNIX level permissions let you
access it. It covers up the problem in Drupal but the issue is still there
regardless.

This also means that any file on the server that is readable by the web server
user can be manipulated via PHP which includes the password file (for
enumerating user names, UIDs and paths), server configuration files (which
are readable by the webuser), other user's files with world read, etc. So if
a given user has world read enabled on a file so that PHP can access it, so
can you and vice versa.

It also (for example) means that PHP "exec()" call is allowed which means that
you have to hope that all scripts sharing space with you on this server are
very careful with how they sanitize user supplied input. There are numerous
third party scripts which do not and if any get installed on this server,
your files are at risk as well because of it.

While "safe_mode" is not the cure all for everything, you should consider it
mandatory for any shared hosting situations you might be involved with. A
goodly portion of the PHP related exploits that have appeared in applications
and the language itself have had their impact greatly mitigated by the
enabling of "safe_mode". The only time I would ever consider turning off
"safe_mode" would be when you have your own dedicated server and even then it
should not be truly be required except in rare cases where you have to rely
on some external application and so must "shell out" to it.

This suggests then some modules have been updated, just not the one you are
using. I would suggest that you post to the Drupal support forums to find
out if there is an updated version of whatever module that is calling
"file.inc" (i.e one which performs a move_uploaded_file() before performing
the final copy() call).

Thus, here we are.

shane birley’s picture

So, it would appear a few lines of code for the uploading of files is requiring some attention.

shane birley’s picture

shane birley’s picture

Will this issue be corrected in 4.6.0? Is this why there is no movement on this problem?

praseodym’s picture

I get the same with 4.6.0.

vidyak’s picture

Hi all
I like having safe_mode on .. but fortunately I have root access to our server so we did a thing and created the directories with the script owner being the directory owner. This is not a tidy work around, but a small thing to ensure security.
Otherwise, I am in love with drupal.
Yours
Vidya

shane birley’s picture

I have updated several sites with 4.6.0 now and I still get the same error. Hopefully, this will be corrected soon. I know that "safe mode" on a PHP server is not overly helpful, but I had a coder review it (who doesn't want to repair it) but he has indicated (as my previous helper) that the code is simple to fix.

(whine)

Yoshia Makino’s picture

Perhaps this thread will shed some light on this problem for shared hosted people:

http://drupal.org/node/5961

4.6.0 did not fix this issue but for those willing, just patch file.inc with

http://drupal.org/files/issues/file_open_basedir_03.patch

ini_set() will not work since the upload_tmp_dir is a PHP_INI_SYSTEM meaning php.ini is the only way to set the variable.

Hope this helps.

shane birley’s picture

Status: Active » Closed (fixed)
morimo’s picture

If you have webmin go to php configuration and check your maximum upload file size.