Cron Feed Update -> passthru has been disabled for security reasons

Tiny Tiny RSS Support
1

Describe the problem you’re having:

Since updating to v20.09-c70e26db3 the feed update process is no longer working. I am using the cron method which is decribed here: Tiny Tiny RSS – Updating Feeds

Running: /usr/bin/php /web/ttrss/update.php --feeds
→ Seems to run without any issues.

System Log shows errors:
passthru() has been disabled for security reasons

  1. classes/rssutils.php(159): passthru(/usr/bin/php update.php --update-feed 117 --pidlock feed-117 , 0)
  2. update.php(239): update_daemon_common(500, Array)

config.php contains:
define(‘PHP_EXECUTABLE’, ‘/usr/bin/php’);

If possible include steps to reproduce the problem:

run cron update command as described in the wiki: Tiny Tiny RSS – Updating Feeds

tt-rss version (including git commit id):
v20.09-c70e26db3

Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:

self-hosted, shared hosting, unsupported. :wink:

Please provide any additional information below:
I cannot run ttrss in docker or the update process as a daemon.

2

it doesn’t make a lot of sense to me to disable exec family of functions for the command line but i guess that’s shared hosting for you.

if there’s a way to check for this at runtime i could add back a fallback mechanism (which is commented out at the moment right after the passthru in rssutils.php) for when passthru() is not available.

<?php
   header("Content-type: text/plain");

   print_r(explode(",", ini_get('disable_functions')));

does this show passthru on your host? you’ll have to run it via PHP command line binary.

3

hey fox,

yes, it does. attached screenshot shows the output.

2020-09-28_18h58_55
2020-09-28_18h58_55899×437 15.2 KB

4

https://git.tt-rss.org/fox/tt-rss/commit/23d20847a3104212b6ecf3d25a1e7d8c52305a4d

untested but should work, i think

5

yep, works again. had to reschedule all feeds with --force-update again, but then it runs through without any errors.

thanks fox
(paypaled)

6

I’m afraid this didn’t work for me. I also ran into this problem a few days ago (also using shared hosting), so I updated my installation from the master branch. I think that function_enabled("passthru") is returning true even though passthru is disabled. I know no PHP, but I tried running the following two commands on the server (via a cron job, which seems to be my only means of access to a shell):

  1. (As suggested above): "<?php header(\"Content-type: text/plain\"); print_r(explode(\",\", ini_get('disable_functions')));" | php -- – this printed an array including [2] => passthru.
  2. (Copying the function function_enabled in rssutils.php): "<?php header(\"Content-type: text/plain\"); print_r(!in_array(\"passthru\", explode(\",\", (string)ini_get('disable_functions'))));" | php -- – this printed “1”.
7

at this point you might as well just comment out the passthru() block and keep the other one.

e: is it actually disabled (but not showing as disabled) or is it missing entirely i.e. what does function_exists("passthru") return?

8

It is showing as disabled: this is the result of print_r(explode(\",\", ini_get('disable_functions')));:

Array
(
    [0] => curl_multi_exec
    [1] =>  dl
    [2] =>  passthru
    [3] =>  pcntl_exec
    [4] =>  pfsockopen
    [5] =>  popen
    [6] =>  posix_kill
    [7] =>  posix_mkfifo
    [8] =>  posix_setuid
    [9] =>  proc_terminate
    [10] =>  ftp_exec
    [11] =>  leak
    [12] =>  posix_setpgid
    [13] =>  posix_setsid
    [14] =>  proc_get_status
    [15] =>  proc_nice
    [16] =>  show_source
)

And in the logs I see:

E_WARNING (2)	classes/rssutils.php:184	passthru() has been disabled for security reasons
1. classes/rssutils.php(184): passthru(/usr/bin/php update.php --update-feed 96 --pidlock feed-96 --quiet , 0)
2. update.php(239): update_daemon_common(500, Array)

Yes I guess I will do that (comment out the block), though it would be nice to be able to run off the mainline code…

9

well, maybe get yourself a VDS then.

10

Hello.

I was wondering about those ‘dangerous’ php functions as I will probably move to a new shared webhosting provider.
So can you disable these php functions separately for CLI and http (scripts)?
(@fox your comment about how you saw little/no sense in disabling these functions for CLI gave me that impression.)
So - if the webhoster supports/allows this - I could ask them to disable those functions for http only and tt-rss (updating via cron) should be have no problems with that?

BTW which functions do you think you should be disabled (for http)? Here’s a list I found:
exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source,fsockopen,socket_create,mail,putenv

Any advice is gretly appreciated. Thank you very much.

11

if they decide to play along, sure. they might have their own ideas though.

maybe it would be better idea to check lowendtalk instead, and get a cheap vds?

e: i wonder if its possible to run tt-rss on a free tier on AWS or something like that, i wonder if some cheapskate have tried that. it can’t be worse than dealing with, uhhh, peculiarities of shared hosting.

12

:grin: nicely put

AWS seems interesting but probably/definitely beyond what I can achieve with my ‘skills’. Should I ever find detailled instructions and the time I’d give it a try for sure.