The statement below appears in several places on the Internet about Drupal security. Is it the case that someone once wrote this and people repeat it in the their '10 Drupal security tips' posts without checking - or is there some truth to it?

Disable user accounts and keep their contents. Deleting users who have created content can lead to access bypass.


  • Can you provide a link or two to the articles that state this? – mpdonadio Mar 11 '14 at 14:26
  • @Clive Georgia Tech is a very reputable engineering school in the US. I can think of one or two scenarios where I would want to test this to see what happens. – mpdonadio Mar 11 '14 at 14:40
  • @MPD I've read it 3 times now. Here's another: drupal.org/node/1732920. I'm not sure what the details are though. I see it on security dos and don'ts check lists. Thanks. – dbj44 Mar 11 '14 at 14:47
  • @24ma13wg The issue was written by a member of the security team, so it is safe to assume that it is a valid concern. Greg is a user here; hopefully he can explain what is going on. – mpdonadio Mar 11 '14 at 14:58
  • 2
    I think this is not an issue unless you grant the "edit own page content" permission to the anonymous user. Previously private content may become visible depending on your node access strategy. Looks like it only affects those nodes that were previously owned by a deleted user, as the access rules can then change once they are owned by the anonymous user. (Different "Greg" here :>) – greg_1_anderson Mar 11 '14 at 21:47

Indeed the page at https://drupal.org/node/1732920 has an example scenario of how this can happen. I don't remember verifying that myself, but believe it came out of some research on an issue reported to the security team. I think Greg_1_anderson's comment about "edit own page content" is probably an important element to that scenario.

I've also seen this happen with node access modules. In discussing it with people, the theory that seems most likely:

  1. User 42 exists and has been granted access to view and/or edit some nodes on a site using a node access module.
  2. User 42 gets deleted, this invokes hooks including in the node access module which may take some action like updating the records it previously stored about user 42 to now point to uid 0 instead of 42
  3. OR...perhaps it forgets update those records and instead they just exist with user 42 on them
  4. When node access records are rebuilt, the code of this node access module either sets faulty records with uid 0 (based on step 2) or it fails to properly load a user and php/mysql will behave in their usual loosely typed ways and take the need for a record with a missing uid value and just insert a zero for the uid.

It's definitely a bug that has occurred more than once. If it can be prevented in code then it should be submitted to that module's issue queue to fix it.

| improve this answer | |

I've seen this happen with no node access modules enabled.

The cause was as mentioned by the Gregs, a user is deleted and all their content was then assigned to anonymous.

Anonymous had incorrectly been given access to edit their own content and so they then had access to edit those nodes.

Note that the sites I have seen this on were drupal 6 sites. This is less of an issue in drupal 7 because you have more control over users being able to cancel/delete users and what happens to their content.

Although having said that, the issue I've seen are largely due to misconfiguration, which can still happen in drupal 7 to get you in that same bad place.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.