Shared data source (.rsds) requires SharePoint View Items list permission for report consumer. - by Qixcle

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 775649 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 1/2/2013 4:24:16 PM
Access Restriction Public


According to product documentation, "Permissions to view or manage a shared data source is different from report viewing permissions; you can view a report that uses a .rsds file without having view permission on the .rsds file itself." --

Based on our own testing, the documented behavior cannot be reproduced in the following environment:

Web Server - SharePoint 2010 SP1 (w/June 2011 CU [refresh]) - Foundation & Server Standard
Web Server - SQL Server 2012 RS Add-in for SharePoint (11.1.3000.0)
Database Server - SQL 2012 Enterprise SP1 (11.1.3000.0)

SharePoint Farm - SQL 2012 SP1 Reporting Services Shared Service Application

Both the application server and database server are guest operating systems on VMware ESX 4.1

The steps to reproduce include the expected behavior when following the expectations set forth in the documentation.  There is also a workaround that is included in the steps to reproduce, but the results do not match the documented behavior entirely.  First, the workaround specifically introduces additional permissions to the shared data source item.  The custom permission will grant the user the ability to enumerate the contents of the Connections document library without granting the ability to assign the shared data source to a new Report Builder Report document.  Attempts to create datasets will raise access denied exceptions.

While the workaround appears to succeed in preventing unauthorized users from creating new report definitions from the shared data source, it does not prevent information disclosure.  As near as I can tell, this may be the result of Report Builder 3.0 executing a WCF call to ListChildren method of the ReportingServices2010.asmx endpoint.  That method demands the ViewListItems (SPBasePermissions) when browsing the Connections document library.
Sign in to post a comment.
Posted by Rich Koneval on 11/21/2013 at 6:53 AM
I have ran into this same situation where we have multiple document libraries that have .rdl files in them and then data source libraries that have the .rsds files in the. So for example we have Report library A and Data Source Library A and Report Library B and Data Source Library B. We don't want the report writers that create reports for Library A to be able to select data sources from Data Source Library B. According to MSDN documentation this should be able to happen and end users could still view reports with out having view rights into the data source libraries.

I read the workaround above which isn't really a good workaround for us. Even though when browsing to the data source library the person would get denied access to the data source library but if they were to try and select the data source from the library via the report they can still view the data sources and select one.

Seems like there should be a solution for this.

Posted by Mariusz [MSFT] on 10/23/2013 at 9:51 AM
Thank you for submitting this feedback. After carefully evaluating all of the bugs in our pipeline, we are closing bugs that we will not fix in the current or future versions of SQL Server. The reasons for closing these bugs are following:
1.     The fix is risky to implement in the current version of the product (service packs)
2.     Scenarios reported in the bug are not common enough
3.     A viable workaround is available
Thanks again for reporting the product issue and continued support in improving our product.

Mariusz Cichomski