The current functionality of the password protect module for G2 is that the target album is password protected, but all descendants (children, grandchildren, great grandchildren, etc.) are not. These descendants have the core.view permissions removed so that when a user tries to directly access a descendant of a password protected album, without being authenticated first, they are redirected to the standard user login page and not the password module's password prompt page.
There were really two options when trying alleviate this issue.
1. Change the module's behavior when adding a password to an album to also add the same password to all descendant objects and remove the changing of the core.view permissions
2. Change the module's behavior to create a list of all descendant objects of a password protected album so when accessing the object directly, the module is smart enough to know that the target object is protected via a password protected ancestor. This option also requires the ignoring of the core.view permissions on the target object.
I went with the second option because it seemed to be the least costly and easiest to maintain. With this change (see patch file), now when an album that is a descendant of a password protected album gets accessed by an unauthorized user, they will be redirected to the password module's password page and not the core user login page.
The change may need to be tweaked a bit to better fit into all user cases, but initial testing on my system for my particular use case (password protected entire gallery by password protecting root album) provided favorable results. The issue I am concerned about is that in commenting out the check for the core.view permissions, I also commented out the check for $isHidden. I am not sure what affect this will have on standard operation since I did not have any hidden albums.
The attached diff was taken against gallery version 2.2.6 and is only applied to module.inc of the password protect module.