In the situation that a file has an ACL with DENY for modify and delete, and nothing set for READ, I would expect that the folder ACL is in the lead with an ALLOW on READ. Correct?
Thanks in advance.
Gustavo
Hi,
File and folder ACLs are not combined in any way. In absense of a file ACL , security for a file is inheritted from the folder. However, if an ACL is specified on the file (either directly or via lifecycle state), that ACL acts as a full override and the folder ACL is not considered .
Hope this helps,
Paul
Thanks Paul for the quick reply.
But where is the READ DENY comming from? There is no ALLOW or DENY in the file ACL.
Guus
Hi,
Default behavior is to not allow unless the user or one of his groups has the 'allow' box checked (and no denies). No check in either 'allow' or 'deny' means the user/group is not prevented from doing the read - but they are not being allowed either. This distinction becomes important when combining user and group permissions together. e.g. a given group may not be specifically allowed access , but the group should not necessarily be prevented either.
Paul
OK, I got it now.
As a result of our security configuration, what we see now, is when we browse through the folder structure the DENIED folders and files are not visible, OK. But when we do a FIND we see files with a NOTACCESIBLE path and we can do a GET. I would expect not to find the file the same as when I browse.
Regards,
Guus
Hi,
Based on the ACLs you've described, it sounds like this is the correct result per the product design. I think the intent is that files can be used in many ways (opened, linked to, etc.) even when you don't have permissions to the containing folder. That said, I do see where an option to aggregate folder and file permissions for file security could a nice feature - this would be a good candidate for consideration on the Idea Station (accessible via the permalinks in the newgroup here).
Paul