API suppresses "empty" ACLs that actually do have effects

  • 1
  • Question
  • Updated 4 months ago
Found an issue with the API related to ACLs.

When requesting AccessControls by Item, any ACL that has all of the CanDownload/CanUpload/etc set to false will not be listed. However, these ACLs do have the side effect that the Principal can see the Item (as an empty folder).

If you explicitly request the AccessControl(principalid=x,itemid=y) the ACL is returned. If no AccessControl exists for principal+item, a 404 error is returned.
These "invisible" ACLs can be deleted, by the DELETE call (which fails for non-existing ACLs but succeeds for invisible ACLs.)

These ACLs are generated when you create an ACL for an Item while the Item's parent has no ACL for the given Principal.

The problem with these invisible AccessControls is that you can't list them (through API) but they do exist and do have effects.
When running a folder access report from the regular web interface, you can see these all-FALSE ACLs but the folder access reports do not show the origin of these lines. Can be user-based but also group-based, and there is no API call to list all distribution groups a user is in. So you need to list and parse all distribution groups (including nested) to see which groups are relevant.

If you create an ACL for /x/y/z while Principal has no access to /x/y then /x/y will be added as all-false ACL. After removing the ACL for /x/y/z, the ACL for /x/y will remain and Principal will see /x/y as an empty folder.

Maybe there's more to this than just the Item's parent, but given this report I expect the dev team can find other cases as well.

Things to be fixed:
- no generation of all-false ACLs (if possible)
- no hiding of all-false ACLs in API (this should be very easy)
Photo of Maarten

Maarten

  • 20 Posts
  • 2 Reply Likes

Posted 5 months ago

  • 1
Photo of Dale Smith

Dale Smith, Employee

  • 137 Posts
  • 19 Reply Likes
Hi Maarten,

I believe what you are seeing is what we call pass through ACLs. Whenever you give permission to an item to a user, where the user does not have permission to the parents of the item, we do create records for the parents so that the user can navigate from a top level folder down to the item rather than needing to know the item ID directly. This is an intentional part of the ShareFile Access Controls. That said, we are supposed to clean up those pass through ACL's when the original access control has been removed, so if you are seeing instances where that does not happen (some times asynchronously so it may not be immediate), it could be a bug. If you have an example (along with the api calls that you have made) I'd be happy to take a look.

Thanks,
Dale Smith
Photo of Maarten

Maarten

  • 20 Posts
  • 2 Reply Likes
Hi Dale,

Simple example: create testfolder1 under Shared, create testfolder2 in 1, create testfolder3 in 2.
Then add user u to testfolder3.
This results in what you call "passthrough" ACLs for testfolder1 and testfolder2 for user u.
Then DELETE https://account.sf-api.eu/sf/v3/AccessControl(principalid=u.id,itemid=testfolder3.id)
Result: "passthrough" ACLs for testfolder1 and testfolder2 still exist.
No async ops here, just plain and simple single-item modifications.
Even when not using API at all but doing this through web interface, the empty ACLs remain.

The idea of "passthrough" ACLs may be intentional, yet they are not handled correctly.
Same as for example someone sharing a sub folder below homefolder to anyone else, results in that other person getting ACL for homefolder. And in the normal web interface it is not even possible to assign people to someone's home folder (let alone remove them). This is definitely not good. Luckily we're able to remove those bogus empty ACLs through API now, based on folder access reports run through web interface, but either these bogus empty ACLs should not be created, and they should not be artificially hidden.
We appeared to have many of these after a year of using ShareFile, and we need to have a way to list & remove them.

This is a simple test case, but I'm preparing a more sophisticated one as I'm seeing things I can't explain yet.


Best,
Maarten

[edit: 2 typo's]
(Edited)