These comments are intended for developers:
I am also able to relieve the problem by directly granting "read_private_data" to the non-admin user on the acs_object representing the class, or by turning off privacy control in the kernel parameters.
It seems that users are getting granted "read_private_data" on the dotLRN object, but that permissions inheritance is turned off for the classes below the dotLRN object.
I'm pretty sure there's a good reason for turning off permissions inheritance below dotLRN. I think Caroline knows something about this.
This will require more discussion with the kernel developer types. I'm talking to Janine trying to get a better understanding of why the read_private_data check is there. She just pointed me to bug 375.
Assuming the read_private_data check belongs there, one solution is to grant "read_private_data" on the "class object" to non-guest users when they are added, and revoke the privilege when they are removed.
