Tac Lite & User Node Permissions [#1001296]

I have found that using Tac Lite seems to override/disregard explicit role defined permissions for content editing.

Our setup is
Running 6.19 w/ Tac Lite 6.x-1.4./ Revisioning 6.x-3.11 / Node Hierarchy 6.x-1.3
Editor Role ~ that has explicit permissions on creating/editing/deleting nodes
Taxonomy Term Role ~ no permissions at all and solely used for the view, view & edit, & delete schemas of Tac Lite

I removed all permissions for a 'page' node in the Editor Role.

When logging in as that editor, the account cannot create a 'page'.

However, using Content List, Node Hierarchy and/or Revisioning screens to list accessible content, that user CAN edit any Pages [whether created by it or another account] so long as the Page was tagged with the corresponding taxonomy term.

I tried manipulating the module weights, rebuilding perms & flushing the caches and nothing clears this out.

Does Tac Lite render core user privs obsolete?

Comments

Comment #1

Dave Cohen commented 17 December 2010 at 17:10

Category:

bug

» feature

This sounds like a configuration problem on your end. Tac_lite can't take away any privileges granted via user roles.

To test, disabled tac_lite then see if the user can edit the nodes.

Comment #2

Dave Cohen commented 17 December 2010 at 17:10

Category:

feature

» support

Comment #3

emersonweb commented 17 December 2010 at 17:34

Thanks for responding:

It isn't taking away privs, it was granting them. The user should not have been able to create/edit/delete the content type. With Tac-lite enabled, the user could edit any content type that met the taxonomy criteria.

I had thought the perms would stack starting with the drupal privs as the base.

I disabled tac-lite as you suggest, and the privs are correct [no create/edit/delete].

Comment #4

Dave Cohen commented 17 December 2010 at 21:19

It can't change the permissions for a content type. But it can for specific content, depending on how it is tagged. My guess is that it works as designed, you just have it configured not the way you want.

The devel_node_access.module (part of devel.module) can help you diagnose the problem

Comment #5

bleen commented 13 June 2012 at 14:35

It turns out there is an issue here but it is not exactly a tac_lite issue ... the way the core node_access module works is as follows:

function node_access($op, $node, $account = NULL) {
  ...
  // Check the normal drupal permissions. If a user has permission to "edit any foo content" 
  // this will return TRUE. If not, this will return null and the node_access function continues.
  $access = module_invoke($module, 'access', $op, $node, $account);
  if (!is_null($access)) {
    return $access;
  }
   
  ... // setup the grants vars in the $sql below by checking the node_access table

  // This sql doesnt take content type into account, so if taclite says a user has access to this content because
  // it is tagged bar and the user can edit content tagged bar then this will return TRUE even if the user
  // should not have access because he/she does not have access to edit foo based on content type. 
  $sql = "SELECT 1 FROM {node_access} WHERE (nid = 0 OR nid = %d) $grants_sql AND grant_$op >= 1";
  $result = db_query_range($sql, $node->nid, 0, 1);
  return (bool) db_result($result);
...

So this is not really an issue with tac_lite but rather its a conscious decision that Drupal has made about the method and order in which access checks and grants are processed.