Forum .LRN Q&A: Forums permissions
I'm just wondering if anybody else is having the same problem with dotlrn forums. I've been doing some testing on my own installation of dotlrn 2.0b4, and found that if I am a user that has been added to a community, and post a message as a new thread, I get a warning message after pressing the OK button. The warning message says that I do not have permission to perform that operation. However when I go back to the forums page, the posting that I attempted to submit is clearly there.
Does anybody know what could be causing this? I've been looking into this bug, but I cannot trace it. Any help would be appreciated.
When I granted read_private_data_p to public my problems went away.
Not sure if its the same problem or not but its something to check.
Where abouts would I have to make this change?
Here is the state of the bug so far. I talked to Joel, Lars, Tilman and Dirk.
Tilman posted a bug. Joel suggested that I go through all forum bugs and assign the blocker ones to Lars. This I will do next.
Tilmanns suggestion was to change forum-security-procs.tcl to use different privileges. On installation of dotLRN the privileges forum_post and forum_create is used. The tcl file expects read, create and write which is right because this was also assigned but somehow it doesn't work.
Now changing each
return [permission::permission_p -party_id $user_id -object_id $forum_id -privilege xyz]
lines to forum_xyz doesn't solve all problems. A normal user can now create a thread but not read his own thread.
After discussion this with Dirk the only way to fix this bug until it is fixed at OpenACS is to do the following.
First do the above changes in forums-security-procs.tcl. So far this not vulnerable.
Next uncomment do_abort in the function require_read_message in the same tcl file. Now the forum works again. But you have a security whole. At least forums will work. Otherwise you have to refrain from offering it until a true bug fix is found.
However, I can reproduce the symptoms described in Nick's original post, and I can eliminate them by commenting out the call to acs_privacy::user_can_read_private_data_p in forums::security::can_read_message_p in forums-security-procs.tcl. So I think Caroline's on the right track.
Aside from other potentially related issues raised in ticket #1338, the relevant question seems to be, what is the appropriate way to handle the read_private_data permission check? That's what I will look at now...
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.
Do we need a check for this before we start the posting procees?
Does the user have read private data p on some objects but not others?
Another thing..if the forum is not under dotLRN then it should not check read_private_data_p as that is a dotLRN concept. Can you take a look and make sure this is the case when you have a chance Andrew.
<blockquote>Does the reader have read private data p on some objects but not others?
Yes, the reader has read private data p on the dotLRN object but no others.
<blockquote>Another thing..if the forum is not under dotLRN...
The forum *is* under dotlrn, but it is not inheriting permissions because security_inherit_p is set to false.
is very different in 4x vs 5x I think that is the root of this bug.
The reason for the protracted discussions is that this bug exposes limitations deep in dotLRN, in the way it manages access to "private" information. We're trying to avoid band-aids here, but I think we're converging. The coding itself will be modest -- most of the work is deciding how to model Guests in the system. Conservatively we should have this resolved in CVS by the end of the week.
More background for programmers:
I've implemented the Guest permissions re-work on our dev server at Sloan and tested for correct function on the forums "one message" page. This, recall, is where we found the bug that exposed the larger problem with Guest status.
I have the following items left:
a) fix the view/add/edit user pages to query the new Guest handling mechanism instead of the old one.
b) test the other places that check for read_private_data
c) test against postgres (already converted most of the SQL)
d) add message keys in a few places