0

I am working on a new Team site collection. And by default I got these Security Groups:-

  • site Visitors -> Read permission

  • Site Owner -> full control

  • Site Member -> Edit

So now let say I add a new discussion board list or a new document libraries to the root site, then users can edit, read items based on which security group they are in.

But now I have noted that there are built-in libraries that are created automatically when I create the new site collection such as Style library, Site Assets, and also non-user related libraries will be added if I enable the publishing infrastructure features. And the problem I found is that the Member users are able to access these libraries , and let say for example I added the site logo, some custom scripts, inside the Style Library then Member users can replace these files or remove them which will cause problems. So I was thinking of stop inheriting permission for these libraries and only allow Members to read these files, so they cannot add/edit/delete files such as the site logo, custom javascript files, etc . so in this case I can be sure that the site assets and style related files will not be modified? So is this valid approach?

Another approach I find, is to grant the Member security group Read permission on the site collection’s root site. And then to create new subsite, which have unique permission and grant the Members the ability to Contribute on the subsite. Then to add any new User-related libraries such as new document library, discussion board, issue tracking to be inside the sub site and not inside the root site . in this case I can be sure that the site collection assets are not going to be modified (such as te site logo, custom javascripts, etc), while users will have contribute permission on the subsites’ user-related libraries ?

So can anyone advice on these 2 points? And which approach is more reliable or recommended?

1

I would simply remove the Edit permission (brake inheritance and set perm as required) in the Style Library for Members. The only real access most users need is the LimitedAccess so the files can be loaded for users that don't have access to library.

  • this is exactly what the logic says,,, so why this is not done by default inside sharepoint ? i mean why sharepoint do not prevent site members from accessing such libraries , and expecting us to do so ! – john Gu Nov 14 '16 at 15:34
  • My guess it is because performance. Sharepoint really, I really mean really ;) doesn't like unique permissions. And each brake in inheritance will cost you a bit. But as you brake on the library level not each item the hit will not be as big, probably within 100ms on initial page load (at least that was on my test environment, so depending on hardware it may be larger or smaller) – Marek Sarad Nov 14 '16 at 16:01
  • i know that unique permission will affect performance,, but we can not eliminate a risk of having contributor users modifying site assets files , because of performance consideration !! – john Gu Nov 14 '16 at 17:37
1

I would recommend 2nd option, it is always better to separate a subsite permissions if you need isolation. first option is not scalable in future, if suppose you are adding other libraries also, you have to do the same steps again of breaking the permission. But 2nd option provides more scalibility, in future if you want anything library list they should be provided read only, you can create in root site and if anything need contributes you can create in subsite.

  • Ok i got your point, and i also like the second approach for the reasons you mentioned... but not sure why sharepoint allow members to managed non-user libraries such as site assets, style libraries, etc.. – john Gu Nov 14 '16 at 13:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.