Forum .LRN Q&A: Forums permissions

Collapse
Posted by Nick Carroll on
Hi,

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.

Thanks,
Nick.

Collapse
2: Re: Forums permissions (response to 1)
Posted by Caroline Meeks on
I had a somewhat different problem with permissions in forums that I traced down to a check for read_private_data_p. This is a permission in dotLRN that is appropriately set if your user is a dotLRN user. However I was on using forums outside of dotLRN on a system that had dotLRN installed.

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.

Collapse
3: Re: Forums permissions (response to 2)
Posted by Nick Carroll on
Hi Caroline,

Where abouts would I  have to make this change?

Collapse
4: Re: Forums permissions (response to 1)
Posted by Lucky Davila on
I'm having the same problem. If anyone knows how to fix it please let me know.
Collapse
5: Re: Forums permissions (response to 1)
Posted by Nima Mazloumi on
I also made the same experience. Am really interested why this happens.
Collapse
6: Re: Forums permissions (response to 1)
Posted by Nick Carroll on
I've noticed that this bug only appears for normal users, and doesn't appear if the same process is done as an administrator.  I still can't trace the bug to the specific piece of code that is causing it.
Collapse
7: Re: Forums permissions (response to 1)
Posted by Nima Mazloumi on
Exactly.

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.

Greetings,
Nima

Collapse
8: Re: Forums permissions (response to 1)
Posted by Tilmann Singer on
The suggestion to revert to forum_xxx privileges is only a temporary workaround until someone cleanly solves https://openacs.org/bugtracker/openacs/com/forums/bug?bug%5fnumber=1338 - just wanted to point that out.
Collapse
9: Re: Forums permissions (response to 1)
Posted by Nima Mazloumi on
that's true
Collapse
10: Re: Forums permissions (response to 1)
Posted by Andrew Grumet on
I will take a look at this today and report back.
Collapse
11: Re: Forums permissions (response to 1)
Posted by Andrew Grumet on
Looking over the this thread and at the code, I'm a little confused about what's going on in Nima and Tilmann's exchange.

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...

Collapse
12: Re: Forums permissions (response to 11)
Posted by Andrew Grumet on
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.

Collapse
13: Re: Forums permissions (response to 1)
Posted by Caroline Meeks on
Hmmm so what I am confused by is how a user who does not have read_private_data_p can even start the forum posting process.

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.

Collapse
14: Re: Forums permissions (response to 1)
Posted by Andrew Grumet on
<blockquote>Do we need a check?
</blockquote>

Probably.

<blockquote>Does the reader have read private data p on some objects but not others?
</blockquote>

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...
</blockquote>

The forum *is* under dotlrn, but it is not inheriting permissions because security_inherit_p is set to false.

Collapse
15: Re: Forums permissions (response to 14)
Posted by Caroline Meeks on
The code for acs_privacy::user_can_read_private_data_p
is very different in 4x vs 5x I think that is the root of this bug.
Collapse
16: Re: Forums permissions (response to 1)
Posted by Andrew Grumet on
Just a quick update -- we're working our way through this bug on the OCT list.  If someone knows the URL where the emails are archived, could you post it?

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:

https://openacs.org/forums/message-view?message_id=45728
https://openacs.org/bugtracker/openacs/bug?bug_number=375
http://grumet.net/writing/programmer/openacs/forum-permissions

Collapse
Posted by Andrew Grumet on
Did I say the coding would be modest?  Doh!

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