Is this script secure when setting a file "above root" to 0777 file permissions?


#1

This is the relevant snippet:

  ###################################################
  $msg = <<< ____TMP          
    PROBLEM:
      Google AMP PAGES require both image width and height.        
      PHP  getimagesize($img) requires downloading file everytime :(

      PREVENT getimagesize($img) from DOWNLOADING EVERYTIME

      INITIAL PAGE RENDERING - ONCE ONLY
        1. getimagesize($img) 
        2. extract width, height and also filesize($im) 
        3. create $figCaptions = string of image figCaptions
        4. save string to file: "above_root/fig-captions.html"  

       ALL SUBSEQUENT PAGE RENDERING
        1. if(file_exists(file: "above_root/fig-captions.html"): 
        2.   $figCaptions = $figfile_get_contents(file: "above_root/fig-captions.html")
        3. endif;
____TMP;

  ###################################################

  $fileFigs = dirname( $_SERVER['DOCUMENT_ROOT'] ) .'/above_root/fig-captions.htm';             
  if( file_exists($fileFigs) ):
    $allImgFigs = file_get_contents($fileFigs);
  else
    // glob(...) and getimagesize(...); script
    // save results
  endif;

#2

Define 'secure'.


#3

Yes, it's secure to put files above the document root. Same way your /etc/passwd file is safe from browser inspection.
No, it's not secure to put files at permission level 777. Same way your /etc/passwd file isnt 777. (By default, it's 644)
Yes, it's secure to write files using PHP above the document root, provided you narrowly define the location of the file.
No, it's not secure to accept user input for the file's contents if they're going to be blindly read and echoed into HTML. Or to allow the user to define the name of the file, without checking for non-filename-characters (including / and .)
etc etc etc.


#4

I don't know how less secure it might be, but IMHO 777 is unnecessarily permissive. AFAIK, typically of "owner", "group" and "world" the only one that might need full permission is "owner". True, if it's above the root "world" should never get there, but I don't like to take chances. And it is not unknown that there have been cases where a vulnerable site infected the shared host (the "group") and spread nasties like rootkits to other sites sharing the host.


#5

@m_hutley, @Mittineague

I tried numerous permissions on both the directory and the file, The only way I could get the web page to save the generated file was to set the directory to 0777. The generated file was then saved as 0644.


#6

What user was the file marked as being owned by when it was created? Consider making that user the owner of the directory and then restricting the permissions down.


#7

The PHP script was uploaded below the root using Filezilla and did not have sufficient permissions to create a new directory above the root.

I used Filezilla to create the directory above the root.

I have read and unsuccessfully tried numerous solutions about changing server permissions. It seems like black magic and as stated the only way to get write permissions was to set 0777 to the directory above the root.


#8

<?php
$fo = fileowner($fileFigs);
chown(dirname($fileFigs),$fo);
?>

?


#9

Many thanks,

I have had no internet for the past three days and look forward to trying the script on my computer.


#10

I tried the script...

<?php
fo = fileowner(__FILE__);
chown(dirname(__file__),$fo);
die;

...and got the following message:

Warning: chown(): Operation not permitted in /XXX/YYY/ZZZ/MY-SITE.com/index.php
on line 16

I also tried the following:

print_r( posix_getpwuid( fileowner($fileFigs) ) ) ==> Array
(
    [name] => root
    [passwd] => x
    [uid] => 0
    [gid] => 0
    [gecos] => root
    [dir] => /root
    [shell] => /bin/bash
)

I also tried numerous Googled solutions without success.

According to the PHP manual:

Attempts to change the owner of the file filename to user user. Only the superuser may change the owner of a file.

As mentioned manually creating a directory above the root and saving a file in the directory works OK and appears to be secure so I will stick with that solution and keep an eye out for other solutions.


#11

Immediate reaction 'eww. server lets the FTP daemon run as root.'


#12

I have never used mod_ftp and access the sites through FileZilla and the Linux Command Prompt; both using SSH Encryption. Is this enough security or is it possible for the FTP daemon run as root to wreak havoc?


#13

Anything running as root is a possibility to wreak havoc.

You trust the FTP daemon not to break its security and allow the user to do things like... delete /

Also if you've got access to the command prompt with root level access why not just chown the directory?


#15

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.