Permission checking for navigation block

Here is an updated version with a proper system_install for mysql.

Working from a fresh install, everything is fine from install.php to initial uid 1 creation. I can add a new user. The form redirects me back to the new user form after I submit a new user user.

However once I logout and login as another user blocks disappear and all pages return not found or access denied.

The patch seems to work well. The code style is pretty clean. I'm having one issue with a fresh install where the menu_roles_cache data isn't quite right. Its inconsistent if I call menu_rebuild as uid=1 and menu_rebuild as another role.

to reproduce start with HEAD patched with menu_65.patch and empty db.
Run installer.

create admin user.
add a new user.
add access comment permissions to 'new user'.
logout as admin
login as 'new user'

I don't see create content or the link to administer comments until I navigate to the 'My Account' page.

It seems to be purely a caching issue. If I run menu_rebuild using the devel module as 'new user' the menu is fine. If I delete from menu_roles_cache while logged in as 'new user' it rights it self as well. It seems menu_tree or _menu_tree may be at fault as that is where data is inserted into menu_roles_cache.

It could probably use some doc around the recursion in _menu_tree.. It took me a moment to wrap my head around it, and I'm not sure I understand it just yet...

I meant add administer comments permission to 'authenticated user' role instead of add access comments permission to 'new user';

/me goes to sleep now.

Starting with a fresh install...

"Create content" block is shown and I have not even created UID=1 yet. Clicking the link to "node/add" says no node types have been added yet. Block still appears for "anon" users even after other accounts have been created. Still says "no content types defined".

Confirmed caching oddity. I created an "admin" role with all permissions checked. Then logged in as this user. When the login finished, I saw two links: "My account" and "logout" -- strange. I clicked "My Account" then the rest of the menu tree appeared. Actually, upon more testing, the whole menu tree disappears when I click on "create content" with this account. Once I click on on "create page" then it appears again. Seems the node/add default page is buggy.

Had another role called "mod" with a different user. Upon logging in, same "my account" and "logout" no other links. Clicking on "my account" and "create content" appears. I gave this user "administer nodes" and "administer content types" but none of those permissions show up in the menu tree. "administer taxonomy" doesn't either. I was then able to take this user to "/admin" and see the whole menu structure. If I clicked on "users" it said page awaits rewrite, menu structure disappeared, and no sublinks. Appears I could reach the root admin menus but no sub ones (except for the ones I had permission to).

Hope that helps!

I tried looking at this patch but it's too complex. I'll have to spend more time with it, but it would be helpful if (a) it was simplified and (b) better documented.

From what I can tell, there are multiple levels of caching and quite a few special cases ("0 means already checked"), etc. Also, I'm not a fan of parameters like '$access_check = TRUE' -- they are a source of security bugs.

While I do appreciate the work that went into this, I think we'll want to simplify this code quite a bit. Otherwise, it won't be very accessible to other people.

I made a separate issue to pull out the comment.module changes as they aren't related to permission checking: http://drupal.org/node/124742

FWIW, I find that this "feature" is counter-intuitive: in usual situations (file systems on *nix, win32, netware, NDS eDirectory...) not granting an access to the parent in a tree blocks access to all of its children, and forcing access to a child node with a specific ACL automatically opens a "traverse" (*nix: "x", NDS: "f") permission to parent nodes to allow logical access to that child, instead of magically displacing it in the tree depending on the permissions of the user.

Is there any reason why our menu system should behave differently ? Consistency with preexisting access models might ease learning this part of Drupal.

I'd agree that blocking access to children if parents are blocked makes more sense, though this places a (quite reasonable) burden on developers to make sure their menu structure and module-defined permissions are in sync.