Nodeaccess: Strange behavior about anonymous content management

At admin -> user management -> access control, under the section "node module", how are the "edit own xxxx content" permissions set for the role "anonymous"?

What happens if you disable all contrib modules? And perhaps optional core modules? And maybe clear (for now) all "edit own xxxx content" and "edit xxxx content" permissions. I can't reproduce the problem.

Do you need to use nodeaccess for the nodes in question? If you just use the standard roles/permissioning system then it should work the way you want...?

I just got bit by this one as well, or something very similar.

I wasn't actually using nodeaccess for anything yet, just had it installed and enabled, but hadn't touched the settings.

Seems that Drupal's default behaviour with a piece of content is to make the author anonymous if the author field is left blank. The author field was left blank after an edit, and immediately the content became editable by anyone visiting the site.

It's a dangerous default to give the author full permissions since it is so easy to make the author anonymous, or have a bunch of anonymous authored content lying around when you first enable the module.

Just to be sure, tested this out with a clean install of nodeaccess on a test site without any settings changed, and content with an empty author is immediately editable by anyone visiting the site.

The issue here is that "edit own" permissions aren't being taken into consideration. You can verify this also by giving view/edit/delete permissions to a role (authenticated users) for example and take away all "edit any" and "edit own" permissions to the roles. You will see that you'll still have the access granted by nodeaccess.

1. add in Nodeaccess "deny edit" and "deny delete" properties with an higher priority then other properies (even on the anonymous user);

Due to how hook_node_grants is implemented, this isn't a possibility.

2. don't allow the Author Settings for "Node author" properties on anonymous users.

This may be a solution, but I think some people might want this still. Maybe a configuration option for this is the better way to go.

I think a better solution would be to implement checks for edit own, edit any, delete own, and delete any in nodeaccess_access.

Any fix for this? This is a big, big security vulnerability--for example, by default, a user's nodes are assigned to Anonymous when a user is deleted. With this bug in nodeaccess, it results in anyone having author-level access to the nodes.

There's no reason for the anonymous user to be treated like other users. It's not actually a user, it's just a placeholder for no user.

grant view permission to a node not working using nodeaccess untill we enable the following permission at admin -> user management -> access control, under the section "node module",
is there any solution to solve this issue ?

zohera: sounds like a separate issue, so I'd suggest creating a separate issue for it.

Subscribing.

I am using the 6.x version of the module and was running into the same problems. I just wanted to ping this thread to say that I've created created a patch for 6.x at #959358: Create additional permissions for anonymous authors.

Changing version back.

don't allow the Author Settings for "Node author" properties on anonymous users.

andyl56 says:

This may be a solution, but I think some people might want this still... Maybe a configuration option for this is the better way to go

No config option needed, that's what the Anonymous User row is for. Unless you want to give anonymous users access only to nodes where their author has been deleted. I can't see a use case for that.

Mine isn't a very good solution, but it's what I just put in place on our site while I look further into the issue and consider applying #959358: Create additional permissions for anonymous authors. I changed node_user() to reset ownership of a deleted user's content to the admin account (uid 1) rather than anonymous (uid 0). For my employer's website this is a sufficient short-term fix, but I may opt to deploy jbylsma's solution.

I have disabled the node author from being able to edit any nodes and rebuilt permissions; anon is still able to edit the specific node where the author was deleted.

Edit: My bad, I should have cleared cache. The edit form was cached for anon users.

The previous comment works well, but if you don't want to hack core you can create a custom module with 1 function in it:

<?php
/**
 * Implements hook_user().
 */
function mymodulename_user($op, &$edit, &$user) {
   if ($op == 'delete') {
    db_query('UPDATE {node} SET uid = 1 WHERE uid = %d', $user->uid);
    db_query('UPDATE {node_revisions} SET uid = 1 WHERE uid = %d', $user->uid);
  }
}
?>

Just make sure this module has a heavier weight than node.module.

Another edit: I wanted to be absolutely sure that an anonymous user can never edit or submit a node; on our site this is the desired behavior. The following function, thrown into a custom module, will achieve that:

<?php
function mymodulename_nodeapi(&$node, $op) {
  // Always disable anonymous editing.
  if ($op == 'prepare' || $op == 'presave' || $op == 'validate') { // Yes, this is probably overkill and only 'prepare' is likely needed.
    global $user;
    if ($user->uid == 0) {
      drupal_access_denied();
    }
  }
}
?>

Apparently this is still a problem in 7.x-1.x-dev :s

This code solved the problem for me:

function hook_node_access($node, $op, $account) {
  if($op == 'update' || $op == 'delete' || $op == 'create') {
    global $user;
    
    if($user->uid == 0) {
      return NODE_ACCESS_DENY;
    }
  }
}

Attached is a patch that will resolve this for 7.x-1.x-dev.

Using hook_node_access, I added an additional check which verifies whether anonymous users really should have access to edit a particular node, and not only because uid=0 became the author via user delete.

I will push this to dev version fairly soon.

Pushed to dev, added to 7.x-1.0 release.

I will backport to 6.x version as well.

Attached is a patch for 6.x-1.3. It will be part of the "new" dev version, as soon as I push the change and create the release.

This patch works similar to one I did for D7 version (logically), except that it uses hook_menu_alter since hook_node_access doesn't exist in D6.

Yikes. Thanks for posting the patch. Glad this one is fixed.

Hey Vlad,

It's been 8 months since patch was made and this bug is still present in "Recommended release" for Drupal 6. I've installed it, maybe a month ago, site was "hacked" yesterday and I had really hard time finding what the problem was and how to solve it.
It's better not to have module at all than to have it with security hole this big.
Please apply the patch to recommended release version.
Regards

Patch does exist and it works, but after 8 months it's still not applied to stable (recommended) release for D6.

New release 6.x-1.4, which includes this patch has been pushed.

Thanks

How can this exists without a security bulletin?