update.php WSOD as anonymous starting with an empty session

[hanoii]

I spent a lot of time debugging this until I found the issue, which I am not sure what it is but at least I found a way to reproduce it on a bare install of pressflow rather than on my drupal site which I am migrating to pressflow.

If you empty the sessions table and run update.php as anonymous (previously allowing this on the settings.php file), once the batch process start you get a WSOD.

I have isolated the reason, however, I am not sure if this is an actual consequence of the pressflow addition to drupal core or if this is actually a bug. Also this is mitigated by the fact that if you do this as the admin user everything seems to work properly, however, it worth mentioning.

The problem appears in

<?php
/**
 * Commit the current session, if necessary.
 *
 * If an anonymous user already has an empty session, destroy it.
 */
function drupal_session_commit() {
  global $user;

  if (empty($user->uid) && empty($_SESSION)) {
    if (drupal_session_started() && drupal_save_session()) {
      // Destroy empty anonymous sessions.
      drupal_session_destroy();
    }
  }
  else if (drupal_save_session()) {
    if (!drupal_session_started()) {
      drupal_session_start();
    }
    // Write the session data.
    session_write_close();
  }
}

specifically in the following snippet:

<?php
  if (empty($user->uid) && empty($_SESSION)) {
    if (drupal_session_started() && drupal_save_session()) {
      // Destroy empty anonymous sessions.
      drupal_session_destroy();
    }
  }

As this function is triggered on a normal drupal_goto() and in the case of an anonymous user and an empty session, the session will be eventually destroyed, so when the update.php is reached again by the batch API, a new session will be generated which leads to a new session ID and then, the batch process is never found because it uses a batch ID and a token which is built from the new session ID and then never found on the db.

If I am explained or pointed in the direction of fixing this I don't mind submitting a patch, otherwise it might be good to either document this or prevent update.php from be run as anonymous.