Default Permissions on Share RRS feed

  • General discussion

  • I'd like to start some discussion here before moving my suggestion to Connect regarding default share permissions. Here's a rundown of what I recently encountered and how it could have been avoided.

    My wife uses iTunes with her iPod, with all the music for her iTunes library being on the WHS in the Music share so I have access to it as well using WinAmp (for the record, I detest iTunes). Anyways, a few weeks ago she complained to me that she couldn't access any of the songs in iTunes, with iTunes reporting that every song in her library was unable to be located. I started digging around, restoring her iTunes library/folder from the nightly backups to no avail; the problem persisted.

    I ran a full system scan with AVG 8.5 and it found a trojan infection rampant through all of her iTunes program files and dll's. Ahh, ok, I found the culprit. Let's get her system clean and then iTunes will work correctly again. I also did a pass with Malwarebytes' Antimalware, which caught a few things AVG did not. Launched iTunes and found no improvement in the situation.

    So finally I wanted to locate a few of the files that were being reported as missing by iTunes and verify that they did in fact exist. Whammo! "Access to this resource has been disallowed." Well that's odd, I thought. I checked the Videos share, same thing. I checked several other shares and they were all reporting the same thing.

    I logged into the WHS console, removed all permissions for her account, rebooted her PC, reapplied the permissions to her user account on WHS and rebooted again. Same results. OK, now I'm getting angry.

    I opened up a remote desktop session to WHS and began to manually verify permissions on the shares. What I discovered was that on every single share that she should have had access to, all the permissions were set to "Deny" for her account. I went through each share granting "Modify" permissions for her account and ensuring that the permissions propagated to all of the subfolders as well. After all had been applied, I opened iTunes once more and voila! Everything played as expected.

    With this newly discovered permissions denial revealed to me (most likely caused by the Trojan she was infected with), I looked again at the permissions set on the shares and I noticed that where a user had been granted "Full" shared folder access, WHS applied a "Full Control" permission to that share instead of "Modify". With users granted "Full Control" their account has the ability to Read, Write, and change permissions or Take Ownership on the share. With "Modify" rights, that user can still Read and Write, but not have the ability to change permissions or Take Ownership. I have to wonder that if the permissions had been set to Modify instead of Full Control, would the Trojan have had the ability to Deny her access to those shares?

    It's probably a safe assumption that the Trojan was not targeting WHS directly, but it may have been searching the local network for shares she had Full Control to and then locking her out of them. As a precaution against future similar attacks, I've changed the permissions on all shares to Modify for any user accounts/groups. The only accounts/group having Full Control are the Administrator and System accounts, and the Administrators group. As far as I can tell, making these permissions adjustments has not adversely affected operations of WHS nor blocked access to anything that the user accounts access.

    Any thoughts or discussion on this permissions setup (particularly from any developers) would be welcome. For example, why was it decided to grant Full Control to these shares when Modify would have fit the bill just fine? Also, any thoughts or scenarios where Full Control would be desirable for a non-admin account? I'd really like to flesh out this whole situation before making a formal product suggestion on Connect.

    Thank you for reading this far and here's to hoping this can be implemented in time for Vail.
    Monday, July 27, 2009 2:46 AM

All replies

  • Best practice: Don't mess with the permissions scheme that Windows Home Server uses. Windows Home Server is not designed to allow for permissions to be managed in any way except through the console, and if you change permissions outside the console, you may find that you've changed them in a way that eventually leads to issues with Windows Home Server.
    I'm not on the WHS team, I just post a lot. :)
    Monday, July 27, 2009 3:14 AM
  • Ken,

    While I understand the "party line" regarding not changing the permissions outside the console, had I not done so in this case the account would remain locked out. I first attempted to re-establish the permissions via the console, but that had no effect. I understand the risks of doing this outside the control of the console, but the question remains, why was Full Control chosen in the first place and not just Modify? Also, as stated, there appears to be no adverse affects of making these changes, so things are working just fine with the permissions dialed down to Modify instead of Full Control.

    Granted, I should have made a similar disclaimer in my original post about changing permissions outside the console, so I'll do that now.

    ***The methods described above for changing permissions is done at your own risk and should not be attempted by amateurs. This is not the recommended method for applying permissions to shares in WHS. In all normal circumstances, permissions should be adjusted via the WHS console application, not the Windows securities dialogs***

    Now, with that out of the way, back to the topic at hand ;)
    Monday, July 27, 2009 3:24 AM