session_start() causes hang

I have some small suggestions and a question/bug report.

The online installation guide contains the phrase "this is done in a screen similar to this:". Looking at the page source, the idea appears to be that this is then followed by this image:
http://cumulusclips.org/wp-content/uploads/permissions.png
However, this gives a "Page Not Found" message.

The same guide mentions various directories that need to be writable by PHP and the web server. One or more of these appear to no longer be part of CumulusClips, e.g. "cc-content/uploads/flv". Personally, I decided to use 0777 on cc-content/uploads/*, i.e. all content in the uploads directory.

The .tar.gz package contains files and directories with write permission for group (g). With index.php in the top level directory, this causes a "Internal Server Error" with my setup.
-----
[Mon Jun 18 11:49:11.082355 2018] [:error] [pid 20132:tid 140079385261824] [client :33852] SoftException in Application.cpp:267: File "/home//public_html/index.php" is writeable by group
[Mon Jun 18 11:49:11.082419 2018] [core:error] [pid 20132:tid 140079385261824] [client :33852] End of script output before headers: index.php
-----
Then, when I remove write permissions from this index.php, I run into this:
http://cumulusclips.org/forums/discussion/1966/
This problem - showing similar errors in the Apache log as pasted above - continues until I've also removed group write permission from cc-install/ and cc-install/index.php. Then I run into the problem below, for which I'm hereby giving a bug report.

So, I've tried installing in both the top level (public_html/) and a directory (public_html/v), as follows:
-----
Top level:
(Note the chmod -R g-w to prevent the issue mentioned above.)

rm -rf public_html/
tar -zxvf cumulusclips.tar.gz
mv -i cumulusclips public_html
chown .nobody public_html
chmod o-rwx public_html/
chmod -R g-w public_html/
chmod 0777 public_html/cc-core/logs/
chmod 0777 public_html/cc-content/uploads/*
cd public_html/
chown -R . *
chown -R . .htaccess
-----
Directory:

tar -zxvf ../cumulusclips.tar.gz
mv -i cumulusclips/ v
chown -R . v
chmod -R g-w v
chmod 0777 v/cc-core/logs/
chmod 0777 v/cc-content/uploads/*
-----

Next up, for both these tries, before getting started, I restarted Apache and removed all PHP's sess_* files. What happens when loading CumulusClips (install) the is the following. I do see the Welcome page, but when I click "Continue" the software loads forever. It's extremely likely that the problem is caused by how session_start() is used. Perhaps - but I'm not sure - the page is calling itself with the same session. If this is the problem, it might be related to this:
https://stackoverflow.com/a/40418669
https://ma.ttias.be/php-session-locking-prevent-sessions-blocking-in-requests/

I did apply all the PHP Settings and installed all PHP Modules mentioned at
http://cumulusclips.org/docs/requirements/
Note that I had to manually add "register_globals = false". I think as it says here
http://php.net/manual/en/security.globals.php
"Warning This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0."
I'm using PHP 5.6 (which matches the required "PHP 5.3+") on CentOS 7.

Damian, any thoughts on how I can continue?

Impressive project, by the way. Is this a one-man project, or are you part of a team? I see you have - or once had - plans for a commercial setup via cumulusclips.com, but that doesn't seem to be up (anymore).

Comments

  • By the way, I see that this forum strips all HTML tags completely, without warning, instead of converting less than and greater than characters to character entities. So here are the commands I used again, but inside code blocks:

    rm -rf public_html/
    tar -zxvf cumulusclips.tar.gz
    mv -i cumulusclips public_html
    chown <account>.nobody public_html
    chmod o-rwx public_html/
    chmod -R g-w public_html/
    chmod 0777 public_html/cc-core/logs/
    chmod 0777 public_html/cc-content/uploads/*
    cd public_html/
    chown -R <account>.<account> *
    chown -R <account>.<account> .htaccess


    tar -zxvf ../cumulusclips.tar.gz
    mv -i cumulusclips/ v
    chown -R <account>.<account> v
    chmod -R g-w v
    chmod 0777 v/cc-core/logs/
    chmod 0777 v/cc-content/uploads/*
  • The install instructions are a bit dated, I need to refresh them. I'm limited in time though because currently it's just me.

    The permissions issue was kinda like an axe to do the job of a scalpel. The best approach would be to give the web server user ownership of the entire codebase. Then you could just set the permissions to just 644 for files and 755 for directories.

    I don't think the session_start issue you linked to is at play here because only request to a php file at a time is being made. There are no race conditions. Besides the group writeable error, are you seeing anything else in your logs?
  • > The best approach would be to give the web server user
    > ownership of the entire codebase.

    Hm, is this a good approach, security-wise? It's not clear to me what your "axe to do the job of a scalpel" remark is referring to, but giving an entire code-base the highest ownership (below root) to get rid of errors feels 'lazy'? Regardless...

    I've tried
    <account>.nobody
    Then Apache's error_log complains:
    Mismatch between target GID (1002) and GID (99) of file "/home/account/public_html/v/index.php"

    So, I then tried
    nobody.nobody
    and
    99.99
    Now Apache's error_log complains:
    Mismatch between target GID (1000) and GID (99) of file "/home/account/public_html/v/index.php"

    This is strange, because 1000 is cpaneldemo, and both
    # ls -Rl|grep cpaneldemo
    and (just in case)
    # grep -r "cpaneldemo" .
    give 0 hits.
  • edited June 23
    I think you misunderstood what I was getting at.

    The script needs Apache/PHP (specifically the user Apache/PHP is running as) to have write access to the files. The reason this is needed is because the script overwrites itself during updates. Also it creates logs, temp files, and moves uploaded files around.

    The scalpel/axe comment was in reference to the instructions we provide people regarding getting their file permissions to work. It requires detailed permissions to achieve what I listed above, but since many people who seek help here typically aren't too technical, we just give them blunt, overkill (and yes lazy) directions in order to keep it simple for them.

    To answer your question about a good approach security-wise, it depends on how Apache/PHP is running. If you're running PHP in CGI or FPM mode then there is no security risk. Just create a basic, plain old user account on your system who owns the files, i.e. /home/michael.

    On the other hand, if PHP is running as an Apache module (php_sapi), then yes it could potentially be a security risk because as you said that user (typically http, apache, or www-data) is not a regular user and could possibly have special access.

    If you're running cPanel, I'm pretty sure they use CGI mode to run PHP scripts (or at least they used to, not sure if it's changed). So placing the script in the home directory of that user and giving the user ownership of all the files should do the trick. Nothing special outside of that should be needed.

    So if your user is called "michael", and cPanel has Apache/PHP configured to run as the file owner, then grant "michael" full ownership of the files, and place them in his home directory, in this case "/home/michael". The permissions from that point on can simply be 755 for directories and 644 for files.

    I'm sure you can lock it down for security sake even further, but that approach is pretty standard and safe, again assuming you're running in CGI or FPM mode.
  • Thanks for trying to help.

    > specifically the user Apache/PHP is running as

    This is "nobody", according to
    # ps auxwww|grep httpd

    And phpinfo() says CGI/FastCGI for "Server API".

    Yes, I'm running cPanel.

    > So placing the script in the home directory of
    > that user and giving the user ownership of all
    > the files should do the trick.

    This doesn't work.
    Here's what happens, to summarize:

    First, I get an "Internal Server Error".
    -----
    [Sat Jun 23 08:03:02.899473 2018] [:error] [pid 21559:tid 140290459358976] [client [ip]:57574] SoftException in Application.cpp:267: File "/home/[account]/public_html/v/index.php" is writeable by group
    [Sat Jun 23 08:03:02.899553 2018] [core:error] [pid 21559:tid 140290459358976] [client [ip]:57574] End of script output before headers: index.php
    -----
    That is with account.account (e.g. michael.michael) ownership.

    Then, when I start removing write permission for the group I run into
    http://cumulusclips.org/forums/discussion/1966/
    etc.

    > [...] and cPanel has Apache/PHP configured to
    > run as the file owner, [...]

    I think this is the problem.

    From
    https://forums.cpanel.net/threads/about-the-file-owner-nobody.56044/

    "If you implement SuExec, scripts etc. run as the user account on the server."
    [...]
    "Its possible that your build of apache did not contain SuExec support. You may need to rebuild apache (from the Software -> Apache Update menu) to include the SuExec module and the PHP SuExec support."
    [...]
    "CGI means PHPSuexec is enabled and scripts should be created with the owner being the cPanel account name. Under CGI, it will be owned and created by 'nobody'."

    EasyApache 3 used to have "Configure PHP and suEXEC". I'm using EasyApache 4. Its "MultiPHP Manager" has a tab "PHP Handlers" that says it's currently using "suphp", with other options being "none" and "cgi". This seems to already be set to what I'd need. ("SuPHP works by running individual PHP files under the user (cPanel user in this case) who executes the script, rather than the default "nobody" Apache user.") However, as I wrote, unfortunately it doesn't work.

    I'll try "cgi" instead, and will install the suEXEC module. I go to "EasyApache 4", click the "Customize" button next to Currently Installed Packages. Then click the Apache Modules tab and search for "suexec". It's already set to "Installed". So, I'll just switch to "cgi" then for the PHP handler. Even though here (some random website)...
    https://www.inmotionhosting.com/support/website/php/choosing-the-best-php-handler
    ...it says "CGI module [...] lacks in both speed and security and is generally not recommended to use."
    Restarting Apache. It does load http://[domain]/v/cc-install/ but then when I press "Continue" I run into the "when I click "Continue" the software loads forever" problem again that I described in my first post.

    There are no error_log files anywhere in CumulusClips' directory. In Apache's main error_log it says:
    -----
    [Sat Jun 23 08:23:30.944219 2018] [cgid:error] [pid 14355:tid 139972148455168] [client [ip]:57918] Script timed out before returning headers: ea-php56, referer: http://[domain]/v/cc-install/
    -----

    Perhaps because I closed the tab that kept loading forever. Just I've tried everything, I'll let it loading for 1 hour (60 minutes), to see if it returns anything - ever. :) One hour should be more than the 1500 max_execution_time. Here goes. (Time to do some gaming.) Okay, it returned after about - I think - 10 minutes with "Gateway Timeout".

    Is there any way I could put some breakpoints or simple print statements somewhere in the code to figure out why isn't not working properly? My feeling, as the subject of the thread says, is that session_start() somehow causes the hang. But I may be wrong. So maybe something similar to this
    http://cumulusclips.org/forums/discussion/1966/
    is happening, where it's looping back to itself?

    For now, I've changed the PHP handler back to suphp.
  • Is my post of June 23 informational enough for you to give some suggestions/ideas?
    Or do you think I may need to look for other video CMS software?
  • edited June 27
    Ok, allow me to regurgitate some of what you just stated to ensure that I understand your situation correctly. Please correct me on any of the following if I am mistaken.
    1. You are running EasyApache 4 with cPanel
    2. In EasyApache 4 you have 3 options for PHP Handlers
      1. none - which would most likely disable PHP support
      2. cgi - which runs PHP under the cPanel user "nobody"
      3. suphp - which runs PHP as the user which owns the files, "account" in your case
    3. You have your CumulusClips files located in the directory /home/account/public_html/v
    4. The directory /home/account/public_html/v is owned by "account.account"
    5. The permissions on the directory /home/account/public_html/v are account.account 755 not 775
    6. The permissions on the file /home/account/public_html/v/index.php are account.account 644 not 664
    Please confirm
  • > Please confirm

    What you write is correct.

    And then, when I visit domain/v/ it forwards me to domain/v/cc-install/ but when I then press "Continue" it hangs.
  • Also, while it's loading endlessly, if I then start a simple test.php with just
    <?php session_start(); print ('test'); ?>
    that too starts loading endlessly.
  • edited June 29
    I think you have two different issues here, the file permissions, and the session_start. Let's address them one at a time, starting with the session_start.

    We are planning on switching the session handler in CumulusClips to a custom approach instead of the default php one, but there is no plan for a release on that yet.

    In php the default session save handler uses a local file based approach. If one request to write to the session file takes too long, crashes, or fails to properly remove the file lock, then subsequent requests that attempt to work with that session file will hang.

    That could be what is happening in your case. If that is the case, you would have have that problem regardless of what script you use. Since that is a server configuration issue, it is outside the scope of this script. Let's run some tests to determine if this is indeed your situation.

    In your previous post you created a test.php file, now please create a second test file "open.php". Give open.php this content:

    <?php session_start(); $_SESSION['test'] = 'test'; echo '<h1>Open</h1> <p><a href="test.php">Go to test</a></p>'; ?>
    Restart Apache so that all existing requests to Apache are terminated. Now open your browser and load open.php. Next click on the link which should take you to test.php. If test.php fails to load or hangs, then your issue is related to the configuration of your server.
  • Did that.

    First, open.php shows:
    -----
    Open

    Go to test
    -----

    Then when I click, test.php shows:
    -----
    test
    -----

    When I edit test.php and use print ($_SESSION['test']);, it also shows:
    -----
    test
    -----

    No problems with this.
  • Would it help if I just gave you all the login information for WHM/cPanel/root/etc., so you could test yourself, including modifying whatever settings you'd want to see how it impacts CumulusClips and its installation process?
  • I have found the solution.
    In ./cc-install/requirements.php I had to change
    exec($phpExe . ' --version 2>&1 | grep "(cli)"', $phpCliResults);
    to
    exec('"' . $phpExe . ' --version" 2>&1 | grep "(cli)"', $phpCliResults);
  • Actually, no, that doesn't solve it.
    But that IS the line that's causing the problem.
  • Is safe mode on? or is exec disabled in php’s disabled functions list?
  • > Is safe mode on? or is exec disabled in php’s disabled functions list?

    This...


    <?php
    ini_set ('display_errors', 'On');
    ini_set ('track_errors', 'On');
    ini_set ('html_errors', 'On');
    error_reporting (-1);

    if (ini_get ('safe_mode')) { print ('On.'); }
    print (ini_get ('disable_functions'));
    print (ini_get ('post_max_size'));
    ?>


    ...returns only "110M" and nothing else.

    I use PHP 5.6.36, which has no safe mode.
    http://php.net/manual/en/features.safe-mode.php
    "This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0."

    This may be informative? https://stackoverflow.com/a/45784653

    Also, this...

    print (posix_getpwuid (posix_geteuid())['name']);

    ...returns the account name; the name that chown's the above test file (and CumulusClips).
Sign In or Register to comment.