Running the cron as guest wont work for a lot of site with grants or node access permission. I would suggest to run it with -u 1, at least for the drush implemenation, not the wget one

provision_backend_invoke($site_name, "cron", array('u' => 1));

If something speaks against this by default, how about having a checkbox in the settings "run crons as superuser"?

iam not sure to mark this as a bug or rather a feature request, starting with a fr.
Any vetos on that?

Comments

eugenmayer’s picture

eugenmayer commented
Title: [site cron feature] run cron as superuser ( -u 1 ) » [site cron] run cron as superuser ( -u 1 )
Category: feature » bug
Priority: Normal » Critical

changing to bug as this destroy node_access settings, making the content not accessable for all user != 1 .. stays until you rebuild permissions with the superadmin.

We have the same issue during migrations btw...

memtkmcc’s picture

memtkmcc commented
Category: bug » feature
Priority: Critical » Normal
Status: Needs review » Active

I don't think it is a bug. By default drupal cron runs as an anonymous via cron.php so I don't see any reason to change drupal default. It also doesn't destroy node_access on any non-cron actions like migrate (which clears all *caches*, which is default Drush behavior). If you think the Drush behavior is wrong, post the issue in the Drush queue. There is nothing "to review" here, btw.

eugenmayer’s picture

eugenmayer commented

Try to run cron with drush without uid=1 on system with grants, taxonomy_acces or solr. I dont mind, fixed for me.

provision_backend_invoke($site_name, "cron", array('u' => 1));

And that is what needs a review.

memtkmcc’s picture

memtkmcc commented

So how it works in all non-Aegir installs? The site's cron is never run with uid=1, afaik?

You didn't attach a patch to be reviewed.

eugenmayer’s picture

eugenmayer commented

it does not work with non-aegir install either...

eugenmayer’s picture

eugenmayer commented

just for the records, if even one is interested:
patch this
./cron/hosting_cron.module:26: provision_backend_invoke($site_name, "cron", array('u', 1));

also see http://drupal.org/node/1075002 for "guest user" crons are "not an issue". Even if its a drupal flaw ( not aegir ), it still needs to be adressed..

eugenmayer’s picture

eugenmayer commented

all related to guest crons .

"0" Status: Request failed: Connection refused in apachesolr_cron

eugenmayer’s picture

eugenmayer commented

woops, after some debugging, that the correct 'patch'

./hosting_cron.module:26:      provision_backend_invoke($site_name, "cron", array(), array('u' =>  1));
eugenmayer’s picture

eugenmayer commented

i have to correct myself, #7 is not a u 1 issue but rather http://drupal.org/node/1080758

anarcat’s picture

anarcat commented
Status: Active » Closed (works as designed)

As mentionned in #1075002: nodeaccess table compromised after site verify ( migration ) and #655808: Allow node access table rebuild, the problem is not with drush or aegir, the problem is with the node_access contrib module. cron.php is *never* ran as the admin user in any Drupal install that I know, so I do not consider this to be an issue with Aegir.