Go 4 Sharepoint

Search:

Welcome: Guest!

MOSS Forum

Home » Forum » MOSS

Ask a question

RSS Feeds

MOSS Search and Share level file permissions

Asked By: Tara Rogers Date: Oct 02, 2006 Category: MOSS Views: 880

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

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

TopFolder
-SubFolder1
- FileA
-SubFolder2
- 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
SubFolder2.

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

Tagged:moss search and share level file permissions

3 Answers Found

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

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, 2006

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, 2006

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).

or

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.