• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 661
  • Last Modified:

Determine where the Web root folder is, relative to the FTP root folder using only PHP commands

I need a reliable way to determine where the Web root folder is, relative to the FTP root folder using only PHP commands.

For the purposes of this question, please assume that the FTP server and the Web server are both running on the same machine and that the FTP server's root folder is an ancestor folder of the Web server's root folder.

eg. On a typical LAMP server:
 $_SERVER['DOCUMENT_ROOT'] == '/home/username/public_html'
 and FTP root folder == '/home/username'

If I use PHP's "ftp_pwd()" command it will return '/' and if I use "ftp_nlist()" it will include the actual 'public_html' folder in the output listing array, but there's no obvious way to establish with absolute certainty if that 'public_html' folder really is the Web root folder.

ps. I'd like to be able to do this for any flavour of Web server and FTP server
0
NetSoftDS
Asked:
NetSoftDS
  • 6
  • 4
  • 2
  • +1
1 Solution
 
Beverley PortlockCommented:
FTP users are usually "chrooted" or "jailed" into a folder and so when they access '/' it refers to their jail folder. Therefore it is not surprising that the PHP functions describe as you behave.

Short of reading /etc/ configurations there is no reliable way to establish which folder is an FTP folder. Most of us define a relationship between the webroot and the FTP folder and use that. It is then only a matter of manipulating the known paths.

for instance, in your example, the FTP folder is always above the public_html folder so you could do something as simple as chopping the path at that point using either preg_match or preg_replace

$ftpPath = preg_replace('!^/[^/]+/[^/]+(.*)$!', '', $webpath);    // untested

0
 
Richard QuadlingSenior Software DeverloperCommented:
On _your_ server, you've got them the same.

I don't on any of my servers.

You would also not know where the physical files are as the ftp root is actually a virtual directory on my server.

That way I can keep everything clean - ftp uploads cannot be accessible automatically via my web server.


What are you trying to do (big picture)?

If you already know that that the ftp root is a is in 'X' and that the web root in is in 'X/public_html', I can't really see what you are trying to find?

Remember, ftp and web are 2 unrelated services. The don't have to exist in the same building, let alone server and directory.

0
 
Ray PaseurCommented:
"any flavour of Web server and FTP server" - simply cannot be done.  You would need to be able to exert some level of control over the PHP configuration.  $_SERVER["DOCUMENT_ROOT"] is not immutable, nor is it always populated.  Most (but not all) PHP installations set it in a useful way.  The same is true of most of the other installation vars.  So I have the same question as Richard has, "What are you trying to do (big picture)?" - we may be able to suggest a workable alternative.

Happy New Year, ~Ray
0
Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

 
NetSoftDSAuthor Commented:
Thank you Experts...

The "Big Picture" is that I have written a PHP CMS, (yes I know... "everybody has one!" ;-), which installs from a ZIP archive. This was done to ensure that the web server was the owner of all the files/folders that needed to be modified, (an important consideration for shared hosting environments). There are however certain instances when I do need to modify files/folders that are owned by the user account rather than the web server. These include:

(1) Changing the web server's root folder's permissions to 0750 after initial installation from the Zip file.

(2) Creating a new file for editing, (or rather publishing the new file, since all editing is done in a draft folder owned by the web server in my CMS).

(3) And also possibly if I decide to extend the CMS to cross-domain editing.

My thinking was that by using PHP's "ftp_chmod()" function the CMS could also change permissions on files/folders owned by the user account, (since the FTP login typically uses the same account as the user). Unfortunately, I immediately ran up against the problem that the FTP server doesn't know where the Web server's root folder is.

I know that this would only be a valid concern where (a) The Web Server and FTP server view the same file system, and (b) the FTP Server can actually see the Web server root folder. This is however generally the case in shared hosting environments, so its not too unreasonable an assumption to make.

... I hope this helps to clarify the situation a little further.

Cheers,
Keith.
0
 
NetSoftDSAuthor Commented:
Hmmm...  Just discovered that Oracle is about to buy MySQL.

This is almost certainly a Bad thing!

My apologies for going off topic, but time is very short, (there's a 4th Jan deadline) and Oracle is doing an excellent job of downplaying and obfuscating the issue.

Here's Monty Widenius' petition URL: http://www.helpmysql.org
0
 
NetSoftDSAuthor Commented:
Ok I withdraw my previous comment regarding Oracle vis-a-vis MySQL, (lowercase "bad" rather than "Bad")... We do after all, still have PostGreSQL :)
0
 
Richard QuadlingSenior Software DeverloperCommented:
Take a look at PHAR : http://docs.php.net/phar

No need to unzip to install. You create the app and make a PHAR and that's it.

You can use chmod()/chown http://docs.php.net/manual/en/function.chmod.php http://docs.php.net/manual/en/function.chown.php if you need to change file perms without the need to access ftp.


As for "reasonable assumption" .... hmmm .... You are asking for trouble.

I would use normal http file uploading and handle all the permissions using the normal file perms.

OR...

Simply don't allow the users direct access to any uploaded file.

Put all the uploaded files out of the way (i.e. no direct URL access) - outside of the webroot/www/public_html folder.

Store the details in a DB along with the user who can access it.

Now you uses the DB to determine what files the user can see. Use this list rather than any direct file scanning process.

 

0
 
NetSoftDSAuthor Commented:
Hi RQuadling,

Thanks for your reply. PHAR looks very interesting too. Unfortunately, I can't use a PHP extension or chmod/chown to manage permissions because this app is designed to run on a shared hosting environment where typically the web server does not have permissions to chown files and folders or to chmod the web server's root folder.
0
 
Ray PaseurCommented:
@NetSoftDS: Have you looked at how WordPress handles this sort of issue?
0
 
NetSoftDSAuthor Commented:
I wouldn't know where to begin looking... I suppose I could look at the WordPress installation guide for clues.
0
 
NetSoftDSAuthor Commented:
Hmmm... By default, WordPress is normally distributed via a Fantastico  script. Fantastico uses exactly the same approach that I do... ie. un-archiving the entire app in-situ so that the web server becomes the owner. Since WordPress doen't need to modify the permissions on the account's web server root folder, (or even need to know where it is), they don't need to deal with this issue.

I should mention that I already have a script that works as long as the following two assumptions are met:

 1) The FTP server and the Web server are both running on the same machine.

2) The FTP server's root folder is an ancestor folder of the Web server's root folder, (ie. both services "see" the same file system).

As has been pointed out earlier in this discussion, these are quite restrictive assumptions and are certainly not generally true... Hence my original enquiry.
0
 
Richard QuadlingSenior Software DeverloperCommented:
PHAR is part of the core of PHP now. Check out your phpinfo() page to see what you've got installed. PEAR is now shipped using PHAR.
0
 
Richard QuadlingSenior Software DeverloperCommented:
There is a lot of ideas here regarding the problems of joining FTP and WEB contents, specifically that there is no way to do it reliably. (bportlock:26153459, RQuadling:26153466, Ray_Paseur:26154442).

An alternative approach to unzipping was suggested - PHAR - which is built into PHP at the core level. PHAR is required by PHP to install the PEAR installation script. As far as I know, PHAR cannot be disabled. (RQuadling:26165027).

I believe there is enough information here to provide a valid PAQ with points split amongst all those contributing.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 6
  • 4
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now