I was playing around with permissions the other day to try and lock a few things down. However I came to some issues with an access denied exception:

14.02.2013 01:43:22.885 *ERROR* [123.456.789.123 [1360766602856] GET /libs/cq/core/content/welcome.html HTTP/1.1] org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught SlingException org.apache.sling.api.SlingException: javax.servlet.ServletException: javax.jcr.AccessDeniedException: cannot read item cafebabe-cafe-babe-cafe-babecafebabe

When a user is first created, they have no permissions, aside from some arbitrary ones on the /home directory. If you log in with this user with these permissions, the browser gives you

No resource found
Cannot serve request to /libs/cq/core/content/welcome.html in /libs/sling/servlet/errorhandler/404.jsp

This makes sense – the user has no permissions to see anything, even the built in 404 error page. If I add read access to the root node for this user, after logging in everything looks as if I’ve logged in as an admin. Permissions shown here:

But if I remove root node read access, and then give every sub node underneath root read access:

and log in after this, the RHS menu errors with:

I could access other parts of the site, but functionality like uploading images to the DAM would also fail with the cafebabe permissions issue. The only noticeable difference between giving the user read access the root node compared to giving them read access to each of its children, was that it’s not possible to manually set read access on the /bin node. Trying to do this gave a popup stating: No modifiable ACL at /bin

No matter what I tried, I was always getting the cafebabe error unless I gave full read permissions to root and everything underneath. Not really the best solution to restricting permissions.

After posting the question on the CQ5 forums, I was informed of the cause. It turns out that cafebabe-cafe-babe-cafe-babecafebabe is the name of the root node in the JCR. While you can get some form of functionality without explicitly setting read access to the root and /bin nodes, some functionality obviously requires it. This is where my confusion was – I thought that it would either work or not, not a kind of half-work.

After learning this, then the solution was quite simple. When creating a user (or more correctly a group to assign users to), first give the root node read access and save. Double click the user/group you’re editing in the navigation pane to refresh it, and then deselect read rights for all nodes besides the root and /bin nodes. Save and refresh again, and then you can add any other permissions you like without having to visit the coffee shop again!

Moral of the story: Users and groups need the right dose of caffeine in order to function correctly.