[2011-05-30] is_cli returns false when cron jobs run with cgi-fcgi about silverstripe-framework

[silverstripe-issues]

comment by: burnbright
created at: 2011-05-30

---

This is how I have modified my own code:

public static function is_cli() {
    return (defined('STDIN') || php_sapi_name() == "cli");
}

[silverstripe-issues]

comment by: @chillu (ischommer)
created at: 2011-05-30

---

is_cli() is a quite security sensitive method, as its determined to allow certain things which are prevented in "non-CLI mode" - so we have to be very conservative with adding any checks here. Could you find some documentation about how the STDIN constant is used, and perhaps examples on how other PHP frameworks detect CLI?

[silverstripe-issues]

comment by: @chillu (ischommer)
created at: 2011-10-18

---

Unsetting milestone

[dhensby]

@chillu I'm having this problem too.

These docs imply that cli mode sets this constant: http://php.net/manual/en/features.commandline.io-streams.php

Though I suppose it wouldn't be impossible to spoof that though...

Couldn't we set some kind of variable if commands are run through sake? So that is just taken for granted that we are CLI?

[chillu]

I guess we could, but would still prefer some built in checks. Same question: This isn't specific to SilverStripe, can somebody please dig up some best practices from other frameworks?

[dhensby]

Funnily enough, I've just spent 10 mins trawling through Symfony's code to find out how they do it and I can't seem to find any real checks (for security purposes) on how they do it.

They reference the constant PHP_SAPI twice in the entire source and it's not used for any security type things, just for debugging levels and similar.

This is the only thing I can find saying how to do it http://www.php.net/manual/en/features.commandline.php#103553

[sminnee]

Don't think we should change this.

[lakinmohapatra]

Hi All . Please go through my blog post related the same issue and i hope , you guys will get the fix.
http://lakinmohapatra.blogspot.in/2016/08/solve-if-php-file-being-executed-by.html

[tractorcow]

Could we declare a constant in cli-script.php that would ensure any subsequent checks for "is_cli" to true? Maybe just after the PHP_SAPI check?

[tractorcow]

in cli-script.php

if(PHP_SAPI != "cli" && PHP_SAPI  != "cgi" && PHP_SAPI != "cgi-fcgi") {
    echo "cli-script.php can't be run from a web request, you have to run it on the command-line.";
    die();
}
define('SS_ENVIRONMENT_CLI', true);

In Director.php

public static function is_cli() {
    return defined('SS_ENVIRONMENT_CLI') || php_sapi_name() == "cli";
}

What do you think @lakinmohapatra

[dhensby]

:S If our CLI script has this check, why isn't the same one used by Director? We could add the constant, but those are pseudo "environment vars" and being on the CLI is not a property of the environment... so it feels nasty.

[lakinmohapatra]

@tractorcow @dhensby @silverstripe-issues , For resolving this issue , we dont need to change core files because basically cron jobs should be run by cli . It's an php environment setup issue for cron user. nothing else.
To fix this, we need to find the exact path to the correct php binary by typing this:
"which php"
This should give you a path like /usr/bin/php. You can go one step further and check if this is actually a "symbolic link" pointing to a different filename or not:
ls -l $(which php)

Output will be like /usr/bin/php -> /usr/bin/php5-cli / may be some other binary
Then add this full path to the PHP executable and use that in your crontab entry, so it looks something like this:

• * * * */usr/bin/php5-cli /home/path/to/artisan schedule:run 1>> /dev/null 2>&1

I hope , it will solve your issue without hacking core files.

[dhensby]

changing core files is not "hacking" if we're fixing a bug... we are maintaining the core files here.

I don't have a problem with cron module identifying itself as running not on the CLI - what OS / PHP versions do you have installed?

[lakinmohapatra]

@dhensby , it will be good if you will write common function for identifying cli jobs.
But i was telling from user prospective.

Possible solutions :
if (array_key_exists('REQUEST_METHOD', $_SERVER)) die();
if (php_sapi_name() === 'cli' OR defined('STDIN')) return true;

But make sure , your cli defending system is covering all scenarios.

[dhensby]

@lakinmohapatra ah, ok. @tractorcow was suggesting a fix that could be used in core, rather than suggesting you amend core files in your project (which of course would be bad).

[lakinmohapatra]

@dhensby , Thanks for understanding my points.

Please review again his codes and see if it's working for all sapi names being mentioned in php.net

[lakinmohapatra]

One more point -
There are lots of advantages of using php-cli instead of other sapi names.
It has unlimited execution time .
It does not write headers to output.
The CLI SAPI does not change the current directory to the directory of the executed script!
When using the CGI version, the output is:
$ pwd

/tmp

$ php -q another_directory/test.php

/tmp/another_directory

This clearly shows that PHP changes its current directory to the one of the executed script.
Using the CLI SAPI yields:
$ pwd

/tmp

$ php -f another_directory/test.php
/tmp
This allows greater flexibility when writing shell tools in PHP.

So i think , it has lots of advantages over other sapi names.
So better to stick with cli check only.
@dhensby please let me know your feedback on it.
http://www.softpanorama.org/Scripting/Phprama/command_line_php.shtml

[tractorcow]

:S If our CLI script has this check, why isn't the same one used by Director? We could add the constant, but those are pseudo "environment vars" and being on the CLI is not a property of the environment... so it feels nasty.

Because it doesn't check if the environment IS cli, it checks if the environment is definitely NOT cli.

cgi-fcgi is still ambiguous.

[sminnee]

Yeah this is a wonfix, I think. I don't think it's worth introducing security risks to cater to an odd configuration.

[sminnee]

We could potentially introduce the if(defined('SS_ENVIRONMENT_FORCE_CLI')) check but leave it up to project developers to create a script where that is defined. They can ensure that the script that defines it is outside of the webroot or similar.

cli-script.php will end up getting exposed to some webservers by a hapless installer and I don't want to see a highway-like security bypass created in those situations.

[dhensby]

It sounds like we can do better at detecting cli, but @sminnee raises a good point about just assuming cli script is run by cli

[tractorcow]

Agreed, #wontfix :)

[dhensby]

I've run into this problem myself and the resolution is to run the cron using php-cli instead of php binary...

Seems like a fairly simple fix and perhaps something sake should be looking for?