Here's a strange one.

I have the following scripts:

module/mymod/blocks/myblock.php
module/mymod/blocks/changemyblock.php

myblock,php displays a block as per usual with a show function. One difference in my block though is that it is a form, and the form ACTION="path_to_mod/blocks/changemyblock.php"
which in turn redisplays the page on which the block was displayed

When the form submit button is clicked you get (for non-admin users) a 'You do not have permission to enter this area' error.

Under XOOPS 2.0, everything works fine.

If I move changemyblock.php to the module root and change the form action to ACTION="path_to_mod/changemyblock.php"
then it works in V2.2 as well!

I have two modules that use this scenario (CDM and EUVAT) and I have noticed something else a bit odd as well;

CDM has both an admin menu and a user side presence. EUVAT does not, it simply has a block, but in order to stop the no permission errors occuring (having moved the action script into module root,) I also have to set
$modversion['hasMain'] = 1;
in the xoops_option.php file to pretend it has a menu. This has the effect of allowing you to set the module access rights for a group on the module. The downside is that you also have to set the order of the module in the module admin screen to 0 (zero) so that a menu item does not display on the main user menu.

So I think there are two bugs:
1/ XOOPS should not restrict access to subdirectories of a module in the way it is doing. $HTTP_REFERRER should tell the security functionality that the calling script is from the home site and allow the action.

2/ XOOPS should not rely on the presence of $modversion['hasMain'] = 1 to determine if access rights are available. If the module is installed, that should be enough.