Groups ACLs on Virtual Folder don't seem to apply

[fostermi]

Hello,

I'm in the final testing stages before rolling sftpgo out to our users and was testing the ACL feature. I'm attempting to recreate what users would expect from a file sharing tool and directory structure whereby certain folders or files can be restricted to different groups. However, I'm having issues getting any ACL to actually work.

I've created a Virtual Folder vtest1 mapped to an S3 bucket, and created created a group sftpgo-test that maps this Folder for all users in this group. This works fine. I then created a "Private" folder inside this Virtual Folder and then placed an ACL on the "sftpgo-test" group to deny access to all files in /vtest1/private directory (there doesn't seem to be an inverse ACL for directories, so I had to use the "Per-directory name patterns restrictions" section).

However, the ACL doesn't seem to get applied. If I login to the UI as a user in the sftpgo-test user group, I can see the vtest1 folder and can view the Private folder and even upload contents to it.

Am I missing something here? Is there any debugging tool available to generate a list of applied ACLs per user or otherwise? Any help would be appreciated.

Thanks as always.

[fostermi]

I think I've sorted out how this works, thanks to the discussion in this issue submission: #1376

In order to deny access to a directory, you need to add the directory to the "Per-directory permissions" and leave the matching rule blank.

One other caveat, is that the inaccessible directory will still be listed. When trying to access the contents, you'll get the message "Failed to get directory listing. Permission denied". If you try to set "Per-directory name patterns restrictions" you'll still be able to see all the files contained within even though trying to download them or view them fails.

[fostermi]

Doing some more testing and I've realized that setting per-directory permissions at a group or user level is counter-intuitive. That is, setting a restriction on a path in a virtual folder in one group then attempting to "open" that restriction via another group leads to no changes as the group permissions are merged. I think the idea of permissions need to be applied at the folder level per group instead of the other way around. That's the way most file systems work. The only way to restrict access is to have unique Folders (backed by unique backend locations) mapped to unique groups.