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

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

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.

"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

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.

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

Ok I withdraw my previous comment regarding Oracle vis-a-vis MySQL, (lowercase "bad" rather than "Bad")... We do after all, still have PostGreSQL :)

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.

 

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.

@NetSoftDS: Have you looked at how WordPress handles this sort of issue?

I wouldn't know where to begin looking... I suppose I could look at the WordPress installation guide for clues.

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.

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.