Search does not work without ReadContent permission

[sobotka]

Hi,
I guess there must be a bug in the Alfresco Search: I have a user who has ReadChildren and ReadProperties permissions in a space (I have a custom role for it). So he can see the contents properties (he can not open the file itself). But when he tries to search (basic/advanced) for a string within filename (or any other property), no result is returned. When he also has the ReadContent permission (like in the Consumer role), the search works ok.

Together with my another post (http://forums.alfresco.com/en/viewtopic.php?f=5&t=23655), it seems to me that the permissions are generally not processed correctly in Alfresco … or am I wrong ?
Petr

[invictus9]

The way Alfresco is doing it is working as intended. Any CMS that lets you search for something when you cannot actually read it is violating security rules.

Here is the "bad" scenario: you have a group of medical records. You want to find someone with an embarrassing disease. You search for all documents with the name/alias of the disease and you get a list of such documents, with the names of who is attached to such documents. Congratulations! You now have a list of people with the embarrassing disease! This is a fundamental privacy issue that Alfresco deals with properly.

To deal with your scenario, you have to have a trusted intermediary do the searching for you. This will let you breach the security constraints in a controlled (and, presumably, monitored) fashion.

[zaizi]

Actually the service service security context is configured to filter out content the current user can not read. This is specified in public-services-security-context.xml. You can re-configure it if you require.

Extract:

<!– All search results are filtered to exclude nodes that the current user can not        –>
    <!– read. Other methods restrict queries to those nodes the user can read                 –>

    <bean id="SearchService_security" class="org.alfresco.repo.security.permissions.impl.acegi.MethodSecurityInterceptor">
        <property name="authenticationManager"><ref bean="authenticationManager"/></property>
        <property name="accessDecisionManager"><ref local="accessDecisionManager"/></property>
        <property name="afterInvocationManager"><ref local="afterInvocationManager"/></property>
        <property name="objectDefinitionSource">
            <value>
                org.alfresco.service.cmr.search.SearchService.query=ACL_ALLOW,AFTER_ACL_NODE.sys:base.Read
                org.alfresco.service.cmr.search.SearchService.selectNodes=ACL_ALLOW,AFTER_ACL_NODE.sys:base.Read
                org.alfresco.service.cmr.search.SearchService.selectProperties=ACL_NODE.0.sys:base.Read
                org.alfresco.service.cmr.search.SearchService.contains=ACL_NODE.0.sys:base.Read
                org.alfresco.service.cmr.search.SearchService.like=ACL_NODE.0.sys:base.Read
                org.alfresco.service.cmr.search.SearchService.*=ACL_DENY
            </value>
        </property>
    </bean>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[sobotka]

The way Alfresco is doing it is working as intended. Any CMS that lets you search for something when you cannot actually read it is violating security rules.

Here is the "bad" scenario: you have a group of medical records. You want to find someone with an embarrassing disease. You search for all documents with the name/alias of the disease and you get a list of such documents, with the names of who is attached to such documents. Congratulations! You now have a list of people with the embarrassing disease! This is a fundamental privacy issue that Alfresco deals with properly.

To deal with your scenario, you have to have a trusted intermediary do the searching for you. This will let you breach the security constraints in a controlled (and, presumably, monitored) fashion.

Sorry but I can not agree with your opinion. It does not make sense (it is not logical):
- not to allow searching in properties if I have the ReadProperties permission and
- allow it if having ReadContent permission (why should ReadContent permission imply to allow group searches ??)

Regarding your scenario if I don´t want the user to see the properties I will not give him the ReadProperties permisssion.

You might be right that in some cases you could need to:
- allow the user to see the properties when the user accessses a given document and
- not to allow the user to make a generall search which would return a set of all documents with some property.
To implement this scenario there should be e.g. a special SearchProperties permission.
As I wrote above, I think this right should not be somehow combined into the ReadProperties permission in this non-transparent manner.

If you write "The way Alfresco is doing it is working as intended" - are you the Alfresco Designer/Developer or is this just your personal opinion that this behaviour was intended ?

Petr

[sobotka]

Actually the service service security context is configured to filter out content the current user can not read. This is specified in public-services-security-context.xml. You can re-configure it if you require.

Zaizi, thanks for your hint.
However if i understand correctly how searching in Alfresco works, it seems to me impossible to achieve what I want.
If I set
org.alfresco.service.cmr.search.SearchService.query=ACL_ALLOW,AFTER_ACL_NODE.sys:base.ReadProperties
then the user who has ReadProperties permission and not ReadContent gets documents which have the searched term in their properties.
But also the documents which have the searched term inside the document (in its content) are returned in the search result !!
This obviously not intended, as the user has not ReadContent permission, so he should not be allowed to know that a document contains the searched term.

I guess the problem is that it is not distinguished whether the searched term was found in the properties or in the content.
Petr

[p_bodnar]

I know this topic is pretty old, but it is still a valid one in some organizations, so maybe my update helps someone...

1) This thread is actually a duplicate of an older one: Change 'read' permission filter on search results? 

2) Note that the described solution won't quite work out-of-the-box if you are running Alfresco with Solr (instead of plain Lucene). Because since the "Solr time", nodes are filtered by permissions by the Solr engine already, by default. Luckily, this filtering can be switched off by setting "alfresco.doPermissionChecks=false" in an appropriate "solrcore.properties" file as described at alfresco - Is post query permission checks possible with solr? - Stack Overflow. So possibly the only question left now is whether this kind of customization can be somehow managed directly in the Solr instead (in order to avoid potential performance degradation?).

And of course, as written by Petr sobotka _‌, there is a to-do on how to differentiate between properties vs. content search (if we wanted to secure the solution more). This is surely doable, somehow, but it's a big question for an Solr / Alfresco expert about how much time one would need to actually do it...

[p_bodnar]

Plus another problem found:

3) If one is missing the ReadContent permission and tries to display details of a file in the Share UI (which always also tries to render preview of the file content, if available), then that operation fails together with Alfresco log being filled with a huge repeated error stacktraces starting with:

REPO_2018-01-30 15:58:43,060  DEBUG [jscript.RhinoScriptProcessor.calls] [http-bio-9080-exec-10] node.get.js Start
REPO_2018-01-30 15:58:43,072  DEBUG [jscript.RhinoScriptProcessor.calls] [http-bio-9080-exec-10] node.get.js Exception
org.mozilla.javascript.EcmaError: TypeError: Cannot read property "isContainer" from null (classpath*:alfresco/templates/webscripts/org/alfresco/slingshot/documentlibrary-v2/node.get.js#10)

So apparently, even the Share's code is not quite prepared for this customization which turns out to be quite a challenging one now...

[toddsykes]

Thanks for posting this. I am doing a small proof of concept and we are also initially looking for the ability to have searchable meta data with at least enough information to request access to content. This is in addition to the normal modes of consumer access and secure content. 

So, it seems that for now, there isn't a great solution for this capability.