I was having troubles with a legacy site that was upgraded from 4.5 to 5.1. When taxonomy access was enabled, the node_access tables were not being updated correctly and direct access to a node via the node url was not being blocked when set to deny. No nodes were properly protected by the access permissions. It failed in all cases.

The issue occurs when a node available in the node and node_revisions tables but does not have a user listed in the user table for the uid listed in the node. It only took one single node without a user to throw off the permissions for all the rest that did have users.

This may be a drupal core related issue related to node_access because I also had the same problem with a test of the forum access module (I tried it when taxonomy access did not work).

Comments

keve’s picture

keve commented

There is a problem in your database.

Normally when deleting a user, normally hook_user is called (in this case node_user w/ $op=delete), this should change the uid values in table node.
The nodes created by the deleted user should change to Anonymous. Node.uid to 0. (AS i remember).

Try to fix your database manually.

On the other hand, this is a security issue.
Leave this issue open, i will check on my system later.

cel4145’s picture

cel4145 commented

Thanks. I already fixed my database. Afterwards, I reset node_access to the default, removed the term_data and term_data_access tables, and reinstalled taxonomy_access. Everything works fine now. It's probably worth noting that taxonomy_access for 4.5 was running on the installation and working properly on the forums on the site with this issue. Once upgraded to 5.1, it was properly hiding the forum listing pages, just not the individual nodes via direct access by URL. I should also note that the offending node status was unpublished (not sure if this would make any difference).

The reason I posted this report is that it was a difficult problem to track down and if someone's user database for 5.1 got corrupted, potentially (I have not tested these cases)

1) any new nodes would be unprotected by the permissions
2) resetting the global access controls for a taxonomy or setting a new set of taxonomy permissions might also fail to properly hide the nodes; nodes containing sensitive information might be googled before anyone noticed the issue.

keve’s picture

keve commented

Thanks for your comment.

There was a big change in access module with drupal 5.x. Now only node.module can write to table node_access, that is it collects permissions from all modules, and after aggregating it, it writes to database.

I will look later, how to protect nodes if node database is corrupted with non-existing uid.

cpugeniusmv’s picture

cpugeniusmv commented
Status: Active » Closed (fixed)

Please reopen if this is still an issue.