Apex Code Development You need to sign in to do that
Don't have an account?
voutcher Attachment security & IsPrivate
We have some strange effects with respect to attachments. They don't seem to behave like a normal object, which is both concerning and limiting. The problem is:
Users are normally restricted to the objects they own and those which are shared with them through the sharing settings. We have shared some of our objects on the basis of roles such that a user can see the records of another in the same department. What we are finding however is the following:
- Attachments can be viewed regardless of whether they have access to the parent record
- Attachments can be found and opened in the quick search even if they have no access to the parent record (most disturbing)
The work around to this is apparently to set the IsPrivate flag, however:
- If you set the IsPrivate flag it doesn't respect the normal sharing settings of the parent object (i.e. it is restricted only to the creator of the attachment.)
- If you set the IsPrivate flag you can't open the attachment but the attachment is still listed in searches (you just get an insufficient privileges error)
- If you don't set the IsPrivate flag any user can see any attachment if they search for something obvious like 'pdf'
Is there a workaround? Is there another setting I should look at? Is the security for attachments just broken?
Thanks for any assistance.
On further review I think what you suggest is happening although this is far from transparent.
The object is private so is restricted but the data (attachment) access apparently is inherited via the customer portal sharing setting.
Would switching off: "Grant Access Using Hierarchies" resolve this?
Voutcher.
All Answers
Voutcher,
What is the sharing profile of the object which the attachment is related to? Attachments will follow the same security as the parent record.
In my own testing if I did not have access to the parent record, I couldn't access the attachment.
thanks,
-Robert
As you say, this is what I would hope for.
There is a parent object (not master detail) with a lookup to this object. The object itself is set to Private for the organisation wide defaults.
The sharing rules are set to : Owner in All Internal Users shared with All Customer Portal Users access Read Only. Could this been the problem is there some kind of inheritance from customer portal users?
There is no sharing rule that allows all internal users to be able to access all other internal users records.
Voutcher.
How is your role hierarchy set up for portal users?
If the sharing rules are set up that user JSmith owns the object, and its shared read-only to all portals users, and user BJones has a portal user beneath him in the role heirarchy, I think the sharing will roll up to BJones.
Can you take a look at your portal user roles and see who is above them in the hierarchy?
Each user is given their default 3 roles but we don't use roles at all in our implementation of the portal users.
The customer portal roles also aren't listed in the role hirearchy tree. Customer portal admins are but they are on the same level as all of the platform users roles in question.
What you suggest be possible but I would still expect that users that don't have access to the object also don't have access to the attachment of that object.
Voutcher.
On further review I think what you suggest is happening although this is far from transparent.
The object is private so is restricted but the data (attachment) access apparently is inherited via the customer portal sharing setting.
Would switching off: "Grant Access Using Hierarchies" resolve this?
Voutcher.
I've now tested this myself and it does work.
I can accept that this is administrator error in this case but it isn't visible or obvious what is happening here (the customer portal roles are not part of the main hierarchy display) and some items are affected by the inheritance and some apparently aren't.
This could have lead to a serious security problem (it would have been so if this had affected one of our other objects). If anyone from salesforce is watching I would suggest that in future options like these are defaulted to the least privileged option.
Thanks for your help!
Voutcher.I'm glad your problem is solved!
I agree that this behavior is more than a little confusing. Check out the new Portal Health Check feature in the Spring 10 release. Its got several awesome features that will help you better secure and administer your portals.
It starts on page 183 of the release notes:
https://na1.salesforce.com/help/doc/en/salesforce_spring10_release_notes.pdf