You are viewing limited content. For full access, please sign in.

Question

Question

user with no access to a folder can bypass via search

Laserfiche Version 10
Updated September 9, 2022
asked on September 9, 2022

I just added a new user to the LFDS and gave them View and Print rights, then went into the repository and changed all BUT ONE folder access to DENY DENY all.  I thought this would make it so that he could not browse (or VIEW) any records in those folders.  But in testing the user can do a search, find, and open any records in those restricted folders.

What do I need to do so that searches are restricted to just that one folder?

0 0

Answer

SELECTED ANSWER
replied on September 9, 2022 • Show version history

It's really hard to say exactly what's happening because the folder structure can be a factor, and "inherited rights" could be disabled on one or more subfolders, which is part of the reason deny isn't the best way to do this.

The better way to restrict them to a specific folder is to ensure that access to your folders/content is not automatically given to Everyone; ideally, your access rights should always require an explicit Allow.

Basically, you should be telling Laserfiche what users are allowed to see and do in most, if not all, instances rather than telling it what they shouldn't see.

What I always do at a minimum is remove all "Everyone" permissions from the repository or only allow Everyone to see the root with "this entry only" access.

Next, I set up repository groups that manage access to different folders, content, features, etc.; this way I rarely have to go in and set access on entries directly.

Then, I just add users or groups to those repository groups. For example, if we want our help desk people to have read only access to Fiscal folders, I just add the Help Desk LFDS group to the "Fiscal - Read Only" repository group.

As a result, I don't have any LFDS groups, users, etc. configured directly in the access rights; it is all handled by the repository groups. Another benefit of this is that editing access rights on the folders/entries requires updates to the ACL tables and can be slow in larger repositories.

On the other hand, adding/removing users from groups is super fast because it doesn't change the ACL tables it just links the user to the existing permissions.

 

In the mean time, one other thing you could do is find an entry they shouldn't be allowed to find via search yet still are, right-click it and check the access rights, choose the user your are having issues with, then do an effective permissions check, which should show you the inheritance information.

0 0

Replies

replied on September 9, 2022 • Show version history

This is expected behavior if the scope of the permission does not include child entries.

You need to set the scope to "This folder, subfolders and documents" because setting DENY specifically on the folder with "This entry only" will prevent the user from accessing or browsing that specific folder and nothing else; it does not inherently restrict the contents of that folder.

There are many legitimate use cases for restricting a folder without restricting its contents. For example, I have a documentation folder at the root of a repository that is hidden from all users; the subfolders for different groups are accessible via search or shortcuts placed in other areas of the repository so I can manage content in one place while still having a user-friendly structure.

 

Is there a reason you're using deny? Generally speaking, best practice for access control is to use deny sparingly since "not allowing" is in implicit denial.

If you're repository is set up in a way that requires that much use of deny, then I'd recommend taking another look at your configuration because "implicit allow" is a sure way to end up in a "fail open" situation like this where people get too many rights unless you explicitly deny.

In reality, it should always be the other way around and "fail closed" because it's better to find out someone has insufficient access and needs to be added to another group or something rather than finding out that someone has too much access.

0 0
View 3 previous replies
replied on September 9, 2022

Thanks, Jason.  This is what I have:

0 0
replied on September 9, 2022

The external auditors for Health & Safety (new Laserfiche User) is the only time we expect to allow anyone into our repository to look around and we want to restrict them to only the files they need to see to complete their audit.

0 0
replied on September 9, 2022

Is there a better way to restrict them to only documents within the Health & Safety folders?

0 0
SELECTED ANSWER
replied on September 9, 2022 • Show version history

It's really hard to say exactly what's happening because the folder structure can be a factor, and "inherited rights" could be disabled on one or more subfolders, which is part of the reason deny isn't the best way to do this.

The better way to restrict them to a specific folder is to ensure that access to your folders/content is not automatically given to Everyone; ideally, your access rights should always require an explicit Allow.

Basically, you should be telling Laserfiche what users are allowed to see and do in most, if not all, instances rather than telling it what they shouldn't see.

What I always do at a minimum is remove all "Everyone" permissions from the repository or only allow Everyone to see the root with "this entry only" access.

Next, I set up repository groups that manage access to different folders, content, features, etc.; this way I rarely have to go in and set access on entries directly.

Then, I just add users or groups to those repository groups. For example, if we want our help desk people to have read only access to Fiscal folders, I just add the Help Desk LFDS group to the "Fiscal - Read Only" repository group.

As a result, I don't have any LFDS groups, users, etc. configured directly in the access rights; it is all handled by the repository groups. Another benefit of this is that editing access rights on the folders/entries requires updates to the ACL tables and can be slow in larger repositories.

On the other hand, adding/removing users from groups is super fast because it doesn't change the ACL tables it just links the user to the existing permissions.

 

In the mean time, one other thing you could do is find an entry they shouldn't be allowed to find via search yet still are, right-click it and check the access rights, choose the user your are having issues with, then do an effective permissions check, which should show you the inheritance information.

0 0
replied on September 9, 2022

Thanks, Jason.  So basically you're telling me that my whole set up is done in a way that does not allow me to restrict individuals... at all.  :(   Other than the ones I already have workflows automatically adding security tags to documents that end up in those folders.

Well, I needed to know.  Now that I do, I'm going to have to do the scary thing of completely revamping our Security on folders.  To allowing groups.  I already have the Office Group set up for forms.  I guess I can switch the entire folder structure over to Officer Group in any place that I previously used Everyone.  Then create an Auditors group and allow that group to the one folder.

0 0
replied on September 9, 2022 • Show version history

Hi Connie,

It doesn't necessarily mean you can't restrict them at all, just that there's a LOT more that can go wrong, as you're seeing now, because you have to find all the things you have to take away and that's a lot harder to anticipate.

I like using food analogies, so if you wanted someone to have a plain burger, it's a heck of a lot harder to pick off toppings, scrape off the cheese, mayo, etc., than it is to just not give them any toppings in the first place.

The best approach is to give people only what they need (least privilege) rather than starting with "the works" and trying to pull things back.

For that reason, "Everyone" can be a risky/problematic thing for access rights.

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...