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." -- http://msdn.microsoft.com/en-us/library/bb326286.aspx#permissionDataSources
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.