Please whitelist cPanel in your adblocker so that you’re able to see our version release promotions, thanks!

The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Can't include files outside of homedir with PHP-FPM (causing ODBC to fail)

Discussion in 'EasyApache' started by pwells, Oct 5, 2017.

Tags:
  1. pwells

    pwells Member

    Joined:
    Apr 28, 2015
    Messages:
    9
    Likes Received:
    1
    Trophy Points:
    3
    Location:
    Australia
    cPanel Access Level:
    Root Administrator
    Hi All,

    We recently migrated to mod_mpm_event and PHP-FPM to handle PHP execution on our server (from mod_mpm_prefork and suphp), however this had strange side-effect of preventing us from including files outside of the homedir for a user's account (in PHP).

    We first noticed this when a website which uses ODBC to connect to a remote MSSQL database stopped working.

    To test this, I created a simple test PHP file which establishes a connection to a defined ODBC data source. Running this from SSH (eg. php -q odbc_test.php ) works correctly - the connection is successful. Even running it as the user's account (eg. runuser -l example -c 'php -q /home/example/public_html/odbc_test.php' ) connects to the data source successfully. However, running this through the web (using PHP-PFM) outputs the below error:
    Warning: odbc_connect(): SQL error: [unixODBC][Driver Manager]Data source name not found, and no default driver specified​

    To further simplify this, I discovered that any file outside of the user's home directory cannot be included or loaded when running PHP-FPM. For example: include "/home/root_file.php"; fails when run through the web, but is included successfully when executed through the command line. The file(), file_get_contents() and similar functions have similar results.

    I can see the benefits of this from a security standpoint, however it appears to break the odbc implementation as the odbc library is unable to load the config files at /etc/unixODBC/. As such, I need a workaround.

    I have looked in every place that I can find to disable this security feature, but cannot find a solution.
    So far I have tried:
    Disabling SeLinux (was already disabled, but listed because it's an obvious solution)
    Disabling mod_userdir (as above)
    Defining the data source as a User Data Sources in ODBC (doesn't work as the drivers aren't loaded)
    Disabling PHP-FPM for that user account (can't get it working on mpm event - gives the error 'Failed to exec' or redirects to the basename)
    Converting the entire server back to mpm_prefork and suphp (FPM doesn't seem to disable - not sure why but it's a production server so I don't have time to debug)
    Modifying the .php-fpm.yaml config file for the account to execute as root (seems to crash php)
    ... and probably a few other things that I've forgotten.​

    I would definitely appreciate some assistance from those with more experience using PHP-FPM.

    Thanks,
    Peter
     
  2. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    38,658
    Likes Received:
    1,425
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    PHP-FPM is enabled separately from the default PHP handler. You can disable it for a specific domain name using "WHM >> MultiPHP INI Manager".

    As far as PHP-FPM and the ODBC PHP extension, I believe the issue you are referencing is a limitation of how PHP-FPM is implemented with user pools. Feel free to open a support ticket using the link in my signature if you'd like us to take a closer look at this.

    Thank you.
     
  3. pwells

    pwells Member

    Joined:
    Apr 28, 2015
    Messages:
    9
    Likes Received:
    1
    Trophy Points:
    3
    Location:
    Australia
    cPanel Access Level:
    Root Administrator
    We also tried disabling PHP-FPM for the domain yesterday (while still on mpm_event), this would not work with cgi (received the error "Failed to exec" when running php files).

    I tried again this morning, switching to suphp as the php handler. This works, php files execute, but seems to have the same issue of being unable to access files outside of the user's home directory.

    Code:
    Warning:  file_get_contents(/home/root_file.php): failed to open stream: No such file or directory in /home/example/public_html/odbc_test.php on line 19
     
  4. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    38,658
    Likes Received:
    1,425
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    That's normal behavior. You should move that file (/home/root_file.php) to the account's home directory to avoid that error message.

    Thank you.
     
  5. pwells

    pwells Member

    Joined:
    Apr 28, 2015
    Messages:
    9
    Likes Received:
    1
    Trophy Points:
    3
    Location:
    Australia
    cPanel Access Level:
    Root Administrator
    I understand that this is normal and good for security, but it was never an issue previously and unfortunately, ODBC appears to rely on being able to include external files in order to load it's configuration files. This gives the below error:
    Code:
    Warning: odbc_connect(): SQL error: [unixODBC][Driver Manager]Data source name not found, and no default driver specified, SQL state IM002 in SQLConnect in /home/example/public_html/odbc_test.php on line 13
    Note that executing the php files from the command line, using the below command, can access the external files successfully (and ODBC works):
    Code:
    runuser -l example -c 'php -q /home/example/public_html/odbc_test.php'
     
  6. pwells

    pwells Member

    Joined:
    Apr 28, 2015
    Messages:
    9
    Likes Received:
    1
    Trophy Points:
    3
    Location:
    Australia
    cPanel Access Level:
    Root Administrator
    Update time.

    I have been in touch with support and we have come to the conclusion that this is most likely not related to php.

    We discovered that when logging in to a jailed shell for the "example" user, we can't see or access files outside of the home directory (with the ls command) - including the test file we had at: /home/root_test.php as well as the ODBC configuration files at /etc/unixODBC/...etc

    We also discovered that using the 'runuser' command does not accurately emulate running the php script as the user. The ODBC library would not load when running php from the commandline inside the "example" user's jailed shell.

    Interestingly, some folders and files are visible within the /etc/ folder, but I can't work out how the system determines which folders to show and which to not show to users running in a jailed shell.


    My current thinking is that this issue is related to CageFS.

    So far, I have tried copying /etc/unixODBC to /usr/share/cagefs-skeleton/etc/unixODBC and updating the skeleton, however this still doesn't seem to show the folder in the jailed shell. What is the correct approach for loading an additional folder in a CageFS skeleton?
     
  7. pwells

    pwells Member

    Joined:
    Apr 28, 2015
    Messages:
    9
    Likes Received:
    1
    Trophy Points:
    3
    Location:
    Australia
    cPanel Access Level:
    Root Administrator
    Got it working!!!

    Once we had determined that this was the result of CageFS not including the required files, all we had to do was create a new configuration file: /etc/cagefs/conf.d/unixodbc.cfg

    Code:
    [unixodbc]
    comment=unixODBC
    paths=/etc/unixODBC, /opt/microsoft/msodbcsql/
    Then force a skeleton update with:
    Code:
    /usr/sbin/cagefsctl --force-update
     
    linux4me2 likes this.
  8. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    38,658
    Likes Received:
    1,425
    Trophy Points:
    363
    cPanel Access Level:
    Root Administrator
    Hello,

    I'm glad to see you were able to get it working. Thank you for updating us with the outcome.
     
Loading...

Share This Page