MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

MOSS Search and Share level file permissions

  Asked By: Tara    Date: Oct 02    Category: MOSS    Views: 2295

Here's a interesting situation when SECURITY TRIIMMING with SEARCH
doesn't work…..

Folder structure like so on a File Server (\\fs01)

- FileA
- FileB

ACL on folders like so

TopFolder - SHARE level permission restricted to certain domain
groups e.g. design
SubFolder1 - read/list FILE level permission set to EVERYONE
SubFolder2 - read/list FILE level permission set to EVERYONE

So if you are NOT in design group, you will not see SubFolder1 or

Now, if we crawl \\fs01\TopFolder\* using an account with read
permission on all folders/files on \\fs01, it will crawl and index
EVERYTHING under TopFolder.

When users, say in the marketing active directory group, do a search
for content in FileA or FileB they come up on the search results
page (Core Result Web Part)

Question: How can I display a "you cannot access this!" type
message in the search results for FileA and FileB to users (e.g.
marketing users) who cannot access these files?

So far, I have tried to look at the managed/crawl properties to see
if any security context type information gets indexed and see if I
can use that in the search XSLT… but nothing has come up



3 Answers Found

Answer #1    Answered By: Kyla Eckert     Answered On: Oct 02

I'm curious to know what version you're running. SharePoint Portal
Server 2003? MOSS 2007?

In any case, I'm guessing that the gatherer/crawler does not index
the share  permissions on the files. If that's true and it only
indexes the NTFS permissions  on the files, then security  trimming by
the search  engine will only take place based on the files' NTFS
permissions. Since the share permissions allow the gatherer/crawler
access to the folder, they're effectively ignored from that point on.

This makes sense. Microsoft has long recommended that security NOT
be set  using share permissions. Share permissions are really only
there for backward compatibility with FAT and FAT32.

Answer #2    Answered By: Alisha Holmes     Answered On: Oct 02

As per the message title, we are using MOSS 2007.

The crawler does only care for NTFS permissions  and this explains the
behaviour we are experiencing. But it also indexes share  level
folders/files. But if user doesn't have permission  to that SHARE, it
won't open that document in the search  result.

My question was how do we display  a padlock icon if the file  cannot
be accessed by the user?

Answer #3    Answered By: Laura Walker     Answered On: Oct 02

I don't think it's possible. If the MOSS 2007 crawler works the same way that the MS Indexing Service does, then it only stores the NTFS permissions  in the index (part of the file  metadata). It won't store the share  permissions in the index. When the file is part of a query result, the query engine only trims the result  based on the security  information stored in the index. It doesn't refer back to the original file to check whether the user has access. It doesn't compare the share level  permissions of the file with those of the user.

I believe that your options are:

1) Modify your security so that they are NTFS only (set all share level permissions to EVERYONE- FULL CONTROL).


2) Write custom code to security trim the results by inspecting the user's group  membership and the share permissions on each file in the result set  (I have no idea how to do this).

Didn't find what you were looking for? Find more on MOSS Search and Share level file permissions Or get search suggestion and latest updates.