Hi Ankur, great module first of all!

It seems there are lots of familiar looking bugs in here, but I hope you forgive me for posting another one since I couldn't find an exact duplicate.

Here's how to reproduce it:
- user B is not in a 'permissions for permissions' group and does not have 'administer nodes' permissions
- user A authors a node, whose default permissions allow A to edit it. I confirmed this after node creation in the database, see below. The node is promoted to the front page, but I don't think it matters.
- user B edits and saves the node

Since B does not have 'permissions for permissions' on that node, it appears that the permissions are ALTERED as a result. What should obviously happen is that the permissions remain unchanged.

BEFORE:

mysql> select * from  node_access where nid=14824;
+-------+-----+--------------------------+------------+--------------+--------------+
| nid   | gid | realm                    | grant_view | grant_update | grant_delete |
+-------+-----+--------------------------+------------+--------------+--------------+
| 14824 |   1 | node_privacy_byrole_role |          0 |            0 |            0 |
| 14824 |   1 | node_privacy_byrole_user |          1 |            0 |            0 |
| 14824 |   2 | node_privacy_byrole_role |          1 |            1 |            0 |
| 14824 |   3 | node_privacy_byrole_role |          0 |            0 |            0 |
| 14824 |   4 | node_privacy_byrole_role |          0 |            0 |            0 |
| 14824 |   5 | node_privacy_byrole_role |          1 |            1 |            0 |
+-------+-----+--------------------------+------------+--------------+--------------+
6 rows in set (0.00 sec)

AFTER:

mysql> select * from  node_access where nid=14824;
+-------+-----+--------------------------+------------+--------------+--------------+
| nid   | gid | realm                    | grant_view | grant_update | grant_delete |
+-------+-----+--------------------------+------------+--------------+--------------+
| 14824 |   1 | node_privacy_byrole_role |          0 |            0 |            0 |
| 14824 |   1 | node_privacy_byrole_user |          1 |            0 |            0 |
| 14824 |   2 | node_privacy_byrole_role |          0 |            0 |            0 | 
| 14824 |   3 | node_privacy_byrole_role |          0 |            0 |            0 |
| 14824 |   4 | node_privacy_byrole_role |          0 |            0 |            0 |
| 14824 |   5 | node_privacy_byrole_role |          0 |            0 |            0 | 
+-------+-----+--------------------------+------------+--------------+--------------+
6 rows in set (0.00 sec)

User B is a member of gid 2, and can no longer access the node he just edited :-(

OFF-TOPIC: I also found out 'administer nodes' overrides NPBR earlier this week. It's not a big deal, but I also thought NPBR somehow overrides it.

Comments

degerrit’s picture

degerrit commented
Title: permissions for permissions & edit priviledge bug (?) » permissions for permissions & edit privilege bug (?)
Version: » 4.6.x-1.x-dev

I can't edit this any more, anyway, this is on 4.6.0. And I think I also had the problem on an installation where the patch described in http://drupal.org/node/22260 was applied.

degerrit’s picture

degerrit commented

Worse: even the author of the edited node seems to change to user B!

ankur’s picture

ankur commented

An update for this issue has been committed to HEAD, DRUPAL-4-6.

Please verify that the update addresses the issues: (1) Random changing of node_access table when the editing user doesn't have permissions to change the permissions, and (2) Changing the author of a node to the person that last edited the node

For some reason, I was unable to reproduce (1), though a closer examination of the code showed possible causes of the behavior.

For line-by-line difference to the previous revision of node_privacy_byrole.module, please see
http://cvs.drupal.org/viewcvs/drupal/contributions/modules/node_privacy_...

-Ankur

P.S. - Thank you for the detailed bug report, by the way. It really helped out.

degerrit’s picture

degerrit commented

Hi again,
Thanks for having a look at this issue! I recently updated to Drupal 4.6.1, so this testing is against a modified 4.6.1.

I did some checking with version 1.17 of your module: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/node_privacy_...

Both issues seem fixed, but here's the catch: there is now a new (I think) problem: when creating pages as a user that does not have the "Permissions for permissions" permission, node_access is not filled in!

mysql> select * from node_access where nid=471;
Empty set (0.00 sec)

After updating this as an admin user things are generally OK, but node_privacy_byrole_user is still missing:

mysql> select * from node_access where nid=471;
+-----+-----+--------------------------+------------+--------------+--------------+
| nid | gid | realm                    | grant_view | grant_update | grant_delete |
+-----+-----+--------------------------+------------+--------------+--------------+
| 471 |   1 | node_privacy_byrole_role |          0 |            0 |            0 |
| 471 |   2 | node_privacy_byrole_role |          1 |            0 |            0 |
| 471 |   3 | node_privacy_byrole_role |          1 |            1 |            0 |
| 471 |   4 | node_privacy_byrole_role |          0 |            0 |            0 |
| 471 |   5 | node_privacy_byrole_role |          0 |            0 |            0 |
+-----+-----+--------------------------+------------+--------------+--------------+
5 rows in set (0.00 sec)

So it now works properly, but only after you have corrected new erronous nodes as admin :-(
Does that make any sense?

Note: the workaround we currently use is to allow all authenticated users 'Permissions for permissions'; but that's not really desirable.

styro’s picture

styro commented

We've also just run into the new problem degerrit mentioned on June 9th - ie the one where nodes are created with an empty set of permissions unless the user has "permissions for permissions" right for that node type. The default permissions for the node type are being ignored when the node is created as far as I can tell.

We have reproduced the problem on a fresh 4.6.1 install with practically no other modules installed.

I'll look into it some more, and hopefully be able to make some more progress.

Should this be a new bug report?

ankur’s picture

ankur commented

This bug has been corrected with the commits posted to the issue at http://drupal.org/25436

-Ankur

degerrit’s picture

degerrit commented

Yep, seems fixed!
Thanks a lot Ankur :-))