Taxonomy Access Control has no effect

Does user role have permission "administer nodes"?

Can you check table node_access, if "view" value is saved right for given node, and given user_role(s)?

The user does not have the "administer nodes" permission.

I don't think the node_access table has the right values. The node in question has a number 1 for the view column on all of its rows. What should I do?

Thanks for getting back to me!

Can you give me a login, so i can peek in (you can send e-mail to me at the contact form)?
If you can, please install devel and devel_access.modules.

Keve, have you gotten my emails? They've been getting bounced back.

IT is OK. I got it.

I found the error:
You have to delete manually:
0 all 0 1 0 0
line from table node_access. This line give "View" access to ALL node. It is intended to be in the database, only if there is no access module installed.

I will check node.module, it should be deleted automatically.
I disabled, then enabled TAC, and that line did was not deleted.

(I enable node_access block to Content area, please switch it off after debugging).

IF you watch the node_access block, when opening pressroom page, you can see that there is no line for gid=1, which is anonymous user, so TAC works well, it denies all access for that page. (No line means all 0s for all permissions) it supplies good values to node.module.
This is a bug of node.module, because it does not delete that line with realm=all.

You can rebuild the total node_access table:
at page: /admin/content/node-settings

Try it.

On your site: i tried node_access_rebuild, (/admin/content/node-settings - although this menu-item does not appear in your admin menu). It did not remove line (0,0,all,1,0,0).

I cannot figure out how is that line remains in your node_access table. I cannot regenerate this. On a fresh install of 5.1, i tested, for me line (0,0,all,1,0,0 ) is always deleted right away, as i enable TAC or when rebuilding node access table (/admin/content/node-settings ).

A tough problem. I haven't made any changes to core files, but is it possible that node.module is corrupt and that is what is causing the problem? I could overwrite it with a fresh copy.

I deleted the line in the database and taxonomy access started working but then the line came back when I changed the taxonomy access settings...

Had the same problem.

You can change function node_access_acquire_grants in node.module from

if (!$grants) {
$grants[] = array('realm' => 'all', 'gid' => 0, 'grant_view' => 1, 'grant_update' => 0, 'grant_delete' => 0);
}

to

if (!$grants) {
$grants[] = array('realm' => 'term_access', 'gid' => 0, 'grant_view' => 1, 'grant_update' => 0, 'grant_delete' => 0);
}

It solved my problem ...

You should not change the node.module in core.

For Flamingvan, we found out the cause.
The problem was a corruption in the database:

Description (in case of flamingvan):
"SELECT nid from node" returns array where nid=4 exists.
node_load(4) return NULL (Because of this node_access_rebuild writes 0,0,all,1,0,0 line into node_access table).

This whole trouble is casued by a corruption between table node_revisions and table node.
In table node: for nid=4, there is a value of vid=1232, BUT this vid DOES NOT EXIST IN "node_revisions" table!
(Vid stands for version_id)

Correct it manually, by setting "node.vid" to an existing "node_revisions.vid"!

You can check for more corruptions like this: "select n.nid, n.vid from node n left join node_revisions r on n.vid=r.vid where r.vid is null "

Yes it was corruption in the database.

Since InnoDB also supports FOREIGN KEY constraints I think that those kind of problems could be prevented in DB layer.

Thank you for help
Bostjan.

Thanks for the fix, I had the same problem. Manifested itself by allowing anyone to visit any forum by typing in the address directly. Forums which were given a View access of ignore or deny didn't show up on /forum but were accessible by typing in the address /forum/34 for example.

A quick update to the previous post. The bug still exists as updating any TAC for any role re-adds the 0 all 0 1 0 0 line to the node_access table.

Elliot: did you try #13?

This bug happens, when a nid exists in table node, but for the given nid the function: node_load(nid) returns NULL.

keve,

select n.nid, n.vid from node n left join node_revisions r on n.vid=r.vid where r.vid is null;

gives no rows (there aren't any.)

The following row shows up with any changes to tac. Deleting the row consistently returns behavior to normal.

Changing the node.module as described in #12 stopped all access to all content, beware.

I also have a bug which I'm not sure is related or even a bug, but I could swear it didn't work this way when I tested it on my test server, and it could be connected, so I'll post it here, but realize this could very easily be unrelated and I should probably open a new request.

99% of my roles have the same access, but a few should be denied access to certain forums. As I understand it, Deny should always take precedence over Allow, but assigning Allow to a forum in Authenticated Users and then Deny to a role of which the restricted user is also a member results in an Allow. This 0 0 all 1 0 0 bug seems to affect permissions globally, so I thought I'd mention it.
-Elliot

Please try this,

http://drupal.org/node/126203

I forgot to mention this patch here.

Keve,
thanks again, the patch listed in #19 appears to have fixed the issue where 0 0 all 1 0 0 is written to the node_access table with each taxonomy access change.
-Elliot

Good to hear.

Try to make a comment for the patch, there in #19, to make it into Drupal core.

BUT beware, in my opinion, the bug was caused because you have a CORRUPTION in your database!

Try to find which node makes the trouble.

"This bug happens, when a nid exists in table node, but for the given nid the function: node_load(nid) returns NULL."

Try to hack node.module by inserting this code into the begining of :node_access_acquire_grants().
It will print out supposedly the problemetic node.

Keve,
once again, thanks for pointing me in the right direction.
For posterity: you can determine which nodes are causing the problems by adding the following to the node_access_rebuild() function. If you add it to the node_access_acquire_grants() as detailed in post #21 it won't print anything useful because the problem has already occurred and the nid isn't available because the node couldn't be loaded.

This will print the node nid for each node which can't be loaded because it is corrupt in some way.

I found roughly 200 nodes where the uid no longer existed in our system. After assigning them all to a valid uid, the 0 0 all 1 0 0 bug appears to have disappeared. You may find other corruption such as nodes with no node_revisions etc. as detailed above. This will return all broken nodes.
-Elliot

You are right. Thanks for commenting back.

As a summary:
This bug gives access to ALL nodes, when there is some corruption in table 'node':
We found two general cause for this:
- vid (file_revision) does not exist in table 'node_revisions'.
- uid (author) does not exist in table 'users'.

I seem to be having this same problem. I have used taxonomy access successfully in my site before and it is still working on some nodes. But I just set up a new vocabulary and applied it to a new node and now I am unable to prevent roles from viewing the restricted pages. I am a Drupal newbie and don't really know how to look in the database. Would it hurt to just apply the patch you mention above? http://drupal.org/node/126203

That patch is not commited to core, so i do not recommand it.
If your database is corrupt, http://drupal.org/node/125355 might help.

Otherwise, read the troubleshoot section in readme.txt of TAC.

Thanks. I looked at the troubleshooting section in readme.txt and I think the problem is that I once installed a module called Node Access. I had already uninstalled it, but according to the readme of node access, "If you deactivate/uninstall, the old entries in the node_access table stick around. I'm not sure if this will cause problems... If you want to get rid of it for good, make sure you run the following query: delete from node_access where realm = 'nodeaccess_rid' OR realm = 'nodeaccess_uid';"

I'll look into that. Thanks again!

tanks Keve and thanks Elliot ...
now it runs fine ... on all the contents i've manually fixed in the db (e.g. removing all the (nid) 0 all 1 0 0 rows)

now i'll keep looking forward to see fixes approved

thanks again
a.

keve, please

i installed the node.module patch ... but it seems neutral ...

infact, for each node i create new the systems add a (nid) 0 all 1 0 0 by default ...
i think this is the wrong behaviour and i'd like to know how to fix it

thanks
a

Please read comment #25.

I have the same problem - taxonomy access has no effect.

- I've tried adding the patch (the one you don't recommend) - it didn't fix the problem so I reverted my nodel.module
- I've tried bostjanvid's solution - it broke my site so I reverted node.module again
- I've checked node_access and I don't have the problem with ..all... lines being inserted
- I've ensured that the restricted users don't have administer permissions on any modules
- I've disabled taxonomy access module, saved, then enabled it again
- I've forced the rebuild of the permissions cache

The only thing left for me to try is installing the Devel Module listed in your troubleshooting guide in the readme.txt. The problem is that this module doesn't show up in the Drupal modules list. Does it still exist?

Has anyone else been as stuck as me and found a solution to make taxonomy access work?

Thank you,

Evan

Evan/TheRaven ... README.txt states

4. For debugging, please install deve_node_access module (Devel module)
This can show you some information about node_access values in
the database when viewing a node page.

u can find it in the CVS at this url

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/devel/

ciao a.