I've been using this module for a long time and have been very happy with it... until yesterday. I found out the hard way how dangerous this module can be. It can give Anonymous users "edit/delete" privileges without your knowing it. For this to happen 2 conditions have to be met:

1) nodeaccess module have to be configured to give edit and/or delete
privileges to the node owner
2) node doesn't have any value in "Authoring information" which defaults to "anonymous" becoming the owner of the node.
I always had condition 1) in place whenever I installed nodeaccess module. This seemed natural to me and I didn't think of condition 2). I still don't know how some of my nodes "lost" their values in "Authoring information" field. I don't remember deleting those values, therefore I just found out that something went wrong when one page became editable by anonymous user and ... you know what that means.

To prevent this from happening again I removed edit/delete privileges from owners in nodeaccess configuration and made sure none of the nodes are owned by "anonymous" by adding some user name in the "Authoring information" field. Luckily owners are still able to edit their nodes if they have a role that has edit privileges on this type of content.

Comments

gintass’s picture

gintass commented

I didn't search for a problem and created a duplicate. Sorry about that. Earlier thread on the topic:
http://drupal.org/node/306541

It answers my question "how 'Authoring information' on some nodes get deleted". It happens when original owner's account is deleted. There is another thread that offers a patch:
http://drupal.org/node/959358
I think this patch should have been implemented long time ago since without it nodeaccess module can cause a lot of trouble.

asb’s picture

asb commented
Category: task » bug
Priority: Normal » Critical

I just ran into the same issue and can fully confirm the analysis provided by gd1008.

After getting lots of content vandalized because I am using an access restriction module is nothing but a major security issue.

And yes, it's "critical" because it's simply is critical if anonymous users can edit and delete content. Basically to prevent stuff like this was the reason to set up access control in the first place...

caligan’s picture

caligan commented

This is not related to Nodeaccess - core behaves the same way. You can replicate this with out-of-the-box core by enabling 'edit own content' and deleting a user so the user's content is reassigned to Anonymous. (This is presumably why D7 now suggests disabling rather than deleting users.)

gintass’s picture

gintass commented

@3
In order to replicate this problem in core, without nodeaccess installed, you have to explicitly grant "edit own content" permission to "Anonymous" user role. I'd say this is a very unlikely situation and if you do that kind of setting, then you shouldn't have a problem if your content is being edited by Anonymous user. Also this is not a default setting in core. In case of nodeaccess, it is set by default to allow the owner to edit content. Even worse - this default setting bypasses role based core setting. In other words even if in core you don't give permission to anonymous role to edit "own" content, as soon as you install nodeaccess and delete owner's account this content becomes editable by anonymous role. That is why I see that this problem is related and caused by nodeaccess, not the core.

BTW where did you see that "D7 now suggests disabling rather than deleting users"?

asb’s picture

asb commented

Deleted users, orphaned nodes, and failed node adoptions are a different topic; these special cases are not the issue here. The problem is that the 'nodeaccess' module breaks access control settings from core. You do not need to delete users to make this happen, so core does not behave the same way.

After having experienced other issues with the 'nodeaccess' module as well, I believe we also have another problem: The current version of 'nodeaccess' is 6.x-1.3 and was released on 2009-Mar-08, this was almost 2.5 years ago. There is no dev release published on the project page, and the module appears to be more or less unmaintained. Not good for security stuff.

So probably the best option would be to get rid of the 'nodeaccess' module and it's inherent security issues; but sadly I wasn't able to figure out which effective access permissions are in place, and that makes it almost impossible to replace the 'nodeaccess' module without accidentally giving broad access to nodes that need to be access restricted. Quite nasty having to guess what the site builder wanted to have restricted, so not even removing the nodeaccess module appears to be an option.

caligan’s picture

caligan commented

BTW where did you see that "D7 now suggests disabling rather than deleting users"?

When you attempt to delete a user, you'll be given a screen to that effect.

I see your point, though having been bitten by the gotcha in core (giving anonymous users edit-own doesn't look dangerous as a new admin until you realize the connection to deleted users' content being reassigned to Anonymous), it just seems like a stronger version of the same. It looks like Content Access may be the better (and more maintained) choice at the moment, although I've quite liked this module.

vlad.pavlovic’s picture

vlad.pavlovic commented
Status: Active » Closed (duplicate)

Duplicate of #306541: Nodeaccess: Strange behavior about anonymous content management, which is why I am closing it.

A fix has been posted to the newly created dev version. I will tag this to a major release within a week or so (when I am able to combine a few more fixes).