Menu
faheem1
By:
faheem1

Unable to upload images specifically on DigitalOcean Server

November 28, 2015 2.8k views
PHP Frameworks DigitalOcean Ubuntu

I have a Laravel site which is running well on a localhost as well as Hostgator Linux shared server. The website allows users to make accounts and upload images and documents in following two directories:

var/www/html/contents/individual/personal/docs
var/www/html/contents/individual/personal/images

Now I have moved it to Ubuntu at DigitalOcean. Here a user can upload a document in the directory "docs" but when he uploads an image in the directory "images", there is an error "[object Object]". Is this related to permissions.

A command "ls -l" gives me following information on permissions:

itsme@MyWebsite:/var/www/html/contents/individual/personal$ ls -l
total 20
drwxrwxrwx 3 www-data www-data 4096 Aug 31 04:29 sounds
drwxrwxrwx 2 www-data www-data 4096 Nov 27 01:22 docs
drwxrwxrwx 3 www-data www-data 12288 Nov 27 01:23 images

Can someone help in resolving this issue. Thanks

Log In to Comment
1 Answer
jtittle1 November 28, 2015

@faheem1

What do the permissions look like for:

/var/
/var/www
/var/www/html
/var/www/html/contents
/var/www/html/contents/individual
/var/www/html/contents/individual/personal

If your web root is www (i.e. where index.php is), from www down to personal should be owned by the same user & group (i.e. www-data) if that's who PHP is being run as (in the case of using PHP-FPM or FastCGI).

--

Security Alert

From a security standpoint, neither files or directories should have permissions set to 0777, which is what drwxrwxrwx implies.

The d tells us that it's a directory while rwx (Read, Write, Execute) is set for Owner, Group and Other (where Other is anyone that is not the Owner and not in the Group). For the directories above, rwx is set for all three of the groups, which is the equivalent of a chmod 777 or chmod 0777.

Ideally, all directories should have a chmod no higher than 0755 and PHP files 0644. Of course, if you can get away with more restrictive permissions, that's a plus.

Why?

Having a chmod of 777 on files or directories, as noted above, gives world-writable permissions. In many cases, when files are written to a directory, they inherit the same permissions unless otherwise set (by your script). Let's say that one user uploads an image that really isn't an image, it's a PHP script in disguise (this could be the case even if it has an image extension). Should this image go by without validation, you now have a script on your server that can do whatever the uploading user wants when they call it. This could be a simple shell command using PHP's shell_exec() function which runs a rm -rf on your entire directory (which would delete everything in it, thus rendering it unrecoverable).

Hopefully you've implemented some validation that prevents this sort of thing from being possible, but this is one example.

Reply
  • faheem1 November 28, 2015

    Hi J Tittle

    Thanks for a detailed reply. I would implement your suggestion to make the directories more secure.

    Just a question, with same permissions/settings of "/var/www/html/contents/individual/personal", if PDF files can be uploaded to the directory "docs" why JPEG files can not be uploaded in the directory "images". Both are at the same level.

    Currently, the permissions of upper directories are give below.

    drwxr-xr-x 13 root root 4096 Mar 24 2015 var
    drwxr-xr-x 4 root root 4096 Nov 1 16:41 www
    drwxr-xr-x 10 admin root 4096 Nov 10 03:50 html
    drwxr-xr-x 12 admin root 4096 Nov 10 01:08 contents
    drwxrwxrwx 5 admin root 4096 Mar 7 2015 individual
    drwxr-xr-x 5 admin root 4096 Mar 7 2015 personal

    • jtittle1 November 28, 2015

      @faheem1

      Is this an NGINX deployment?

      Looking at the permissions set for ./html/ down to ./personal/, there's your culprit. The user and group that PHP is running as needs to also be the user and group that is set to own the files and directories set in the home path.

      The exception to this rule would be /var/ and /var/www/, you should leave both of these directories owned by root.

      --

      For example, if PHP is running as www-data, which it seems to be from your original post, then you need to chown (change ownership) on ./html/ down to www-data.

      To do this, you'd ideally want to do it recursively, so we'd use:

      chown -R www-data:www-data /var/www/html

      This command will leave /var/ and /var/www/ owned by root while changing ./html/ and down (all files + directories) to be owned by the user & group www-data.

      That said, if PHP is running as another user, then you need to replace www-data with that user.

      --

      In terms of security, you should never run PHP as root (or any other service). Using the example I provided above, if you choose to run PHP as root and you were exploited, that rm -rf command could easily end up wiping your entire server (and it can be executed from PHP as running as root gives your scripts the highest of permissions).

      • faheem1 November 30, 2015

        @jtittle

        Thanks again. I have set "chown" as you suggested and now Apache (www-data) is able to load contents in the "images" directory :)

        Earlier you suggested 755 for directories and 644 for files. Does that also apply to all sub-directories in root such as bin, boot, dev, etc, home, root, run, var, and many more. In that case, in my top most directory, I would just run this command for a server-wide change.

        find . -type d -perm 777 -exec chmod 755 {} \;
        find . -type f -perm 777 -exec chmod 644 {} \;

        Currently root is owner for all the directories in the top most "root" directory.

        • jtittle1 November 30, 2015

          @faheem1

          No :-).

          You do not want to run those commands from a directory other than the ones you're serving content from (specifically, the ones mentioned above).

          The OS (Operating System) has a very specific structure and altering it may render your system unusable. Those commands are recursive, meaning they do not stop until there is either:

          1). No files left to modify or;
          2). No directories left to modify.

          This means that should you ever run it from /, all of the files and dirs at the root of the server will be modified which is not a good thing.

          --

          Sorry for the use of bold text, just trying to make sure I get the point across not only for you, but for others that may read this post as well :-). When it comes to permissions, they can either make or break your site and server and running such automated commands leaves you with very few options should you choose to run them elsewhere other than where specified.

          If those commands were to be ran from /, your best option would be to redeploy and start over as there's thousands of files and you'd need to know exactly which ones had which values (the same for directories).

          --

          Unless you have a very specific reason to modify directories other than those within:

          /home/....
/var/www/....

          Leave everything else alone :-). Those are the two main dirs where content is placed on most servers (most, not all, but going outside those is really more of preference). Anything else should only be modified when and if instructed or you're absolutely sure you know exactly what you're doing.

  • Zachary_DuBois November 29, 2015

    @jtittle Props for mentioning the 777 :)

Have another answer? Share your knowledge.

Related Questions