Project:Search Files
Version:6.x-2.x-dev
Component:Search Attachments
Category:bug report
Priority:critical
Assigned:Unassigned
Status:closed (fixed)

Issue Summary

The search_attachments module displays all the attached documents where the querystring is found, even the documents attached to nodes that the user hasn't got the permission to view.

Example : in my site, an anonymous user can see can find and see attached documents to private nodes.
I use the taxonomy access control to handle the node access.

Comments

#1

Title:saerch_attachment and node access» search_attachment and node access

#2

Subscribing

I have installed node_access as well as search_files. I created a content type called PDF and generally granted all roles other than anonymous permission to search files. But I have posted specific pdf files that only organization leaders and administrators may view. The nodes are not visible to anyone else, but a low-level authorized user who searches files gets a list of attached files and can view those files.

This is an important security issue.

#3

When this feature will be added? I really need it. I use the module "content access" (http://drupal.org/project/content_access).

Thanks!

#4

Version:6.x-2.x-dev» 6.x-2.0-beta4

#5

I would also appreciate this feature.

#6

Tracking. Very important that it respect access control.

#7

Will this feature be compatible with "Private Upload" module (http://drupal.org/project/private_upload)? It's important for me!

#8

Should this be considered a security issue? (Private data is being made available publicly in the current version of the module.)

#9

Category:feature request» bug report
Priority:normal» critical

It's a security bug. Tracking it.

#10

Subscribe

#11

As a quick fix, I added a node_access check right after the node_load in search_files_attachments.module file.

        $node = node_load($file->nid);
        if (node_access("view", $node)) {
          $realpath = realpath($file->filepath);
          if (is_file($realpath)) {
            $fileinfo = (object)pathinfo($realpath);
            $results[] = array(
              'link' => file_create_url($file->filepath),
              'title' => $file->filename,
              'user' => theme('username', $node),
              'date' => $file->timestamp,
              'type' => check_plain(search_files_helper_name($fileinfo->extension)),
              'node' => $node,
              'score' => $item->score / $total,
              'extra' => array(l(t('Node'), "node/" . $node->nid)),
              'snippet' => search_excerpt($keys, $file->data),
            );
          }
        }

The pager doesn't work properly with this though. I would guess db_rewrite_sql should be used somehow with do_search.

#12

subscribe

#13

Status:active» needs review

Please test the attached patch against the latest dev release.

This patch should also delete files from the search index if they have been removed from a node, or a node is deleted.

AttachmentSize
search_files_attachments-access-and-delete.patch 4.7 KB

#14

drenton, your patch in #13 seems to work very well for me. Like the OP, I am restricting access to certain nodes via the Taxonomy Access Control module and the search results now respect the privileges granted through the module.

#15

I installed the dev version and applied the patch. The module appears to be working correctly now and respecting access permissions.

Thanks for the fix

#16

Thanks for this. When will the patch be added to the Dev version officially?

#17

Subscribing....

#18

Version:6.x-2.0-beta4» 6.x-2.x-dev

Just made a couple of changes from patch on comment 13.

- removed the private file system patch ( http://drupal.org/node/598136 ) from this patch
- change in hook_nodeapi to check if $node->files is an array or object

AttachmentSize
search_files_attachments-507298-18.patch 4.5 KB

#19

Status:needs review» patch (to be ported)

i tried and works, so i put to be ported :)

#20

Status:patch (to be ported)» fixed

I have committed the patch in #18

#21

thanks @jrglasgow to take care of us :)

#22

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.