|
BACK to Menu!
grum: So I'm trying to make my uTorrent target folder E-gonorrhea proof (In Vista Home Premium) I denied the 'read + exceute' (which also removes 'read' and 'list fiolder contents') permission from the system, but do I have to do this for all the users as well? Or do I have to go into the advanced settings for 'effective permissions' and deny 'execute/transverse folder' too. Am I even remotely on the right track??? I still want to be able to seed the torents, if possible. There's a difference between NOT Granting a permission versus DENYING a permission. Normally what you want to do is NOT Grant (uncheck) permissions that you don't want to grant, or remove the security IDs (group/user name) entirely. Granting permissions always overrides NOT Granting permissions. If you don't grant permission to EVERYONE then grant permission to USERS, the USERS will be given permission (they belong to at least one group granting permission). Denying permissions always overrides granting permissions. If you deny permission to EVERYONE then grant permission to USERS, the USERS will still be denied permission (they belong to the EVERYONE group that is DENIED). Here is how Windows decides on permissions. 1. If the account belongs to a group or user denied a permission, the permission is denied (done). 2. Or else, if the account belongs to a group or user granted permission, the permission is granted (done). 3. Or else, neither granted nor denied permission then the permission is not granted. The "owner" of a file/folder has special permissions. The "owner" of a file/folder can always change permissions even if changing permissions is denied (or not granted). Administrators have special permissions. Administrators can always "take ownership" of a file/folder even if that is denied. An administrator can't change permissions if that right is denied (and they aren't the owner). To get around that an administrator has to take ownership of the file/folder to change permissions and then it is obvious who changed the permissions. Permissions set on a folder can be applied to any or all of these three things. - This Folder (applies folder permissions to just that one folder) - Subfolders (applies folder permissions to just subfolders and their subfolders) - Files (applies file permissions to files in that folder and files in subfolders) If you select the option to "apply to objects or containers within this container only". - This Folder (applies folder permissions to just that one folder) - Subfolders (applies folder permissions to folders directly under that one folder) - Files (applies file permissions to files in that one folder) You can add the same SID (user or group) multiple times in the permissions, providing that the permissions don't apply to the same things. For example, you can grant EVERYONE write permission for folders, but not grant EVERYONE write permission for subfolders. You can deny EVERYONE read permission for files. You can do all of those at the same time using the permissions on one folder. To DENY execute permission for the files in a folder and files in all subfolders, you only need to apply the permissions to "files". Deny the Execute permission for the "files". You set the permissions on the containing folder, and then select "files" in the box that says "Apply on to". If you literally don't want anyone to be able to execute files located there, then you can DENY Execute permission to EVERYONE. Make sure that you only apply that to "files" because applying it to "folders" or "subfolders" will deny the ability to access the folders or subfolders. The confusing thing is that many folders already inherit permissions. You may have to turn off inheriting permissions on a folder or file before you can set the permissions that you want. You are given the option of copying existing permissions (which I recommend that you use). Then remove users or groups that you don't want to grant the permissions to. You can also change an entry for a user or group to grant less permissions (or none at all). Using DENY will let you deny permissions that are granted by inheritance. That means you don't have to turn off the option to inherit permissions. Just keep in mind that you can't grant a denied permission using some other SID (user/group) in the permissions for a folder/file. You can grant a permission that is "not granted". If you have a subfolder inheriting a denied permission, you can turn off inheritance of permissions, and then the "denied" entries won't be inherited. Then just grant the permissions that you want by adding groups or users to the permissions. Turning off inherited permissions also applies to subfolders and files (they won't inherit any of the permissions that the folder didn't inherit). They will inherit permissions that you set on the folder (unless you also disable inheritance on the subfolders). Here is how inheritance works. For a folder, the folder may inherit ALL the permissions from its parent folders or NONE of the permissions from its parent folders. The inherited permissions can be for files, folders or both. Next, a folder can have permissions set on it, for files, folders or both. A file can inherit ALL of the file permissions from the parent folders containing it, or NONE of the file permissions. Next, a file can have permissions set on it (applicable to files) and those permissions only affect that one file. Inheritance of permissions can be controlled in two different ways. Any file/folder can be set to NOT inherit permissions from parent folders. A file or folder permission specifies what objects (below it) should inherit the permission. The choices are any (or all) of Files, Folders, and Subfolders. Even if a file or folder is set to inherit permissions from parent folders, it will not inherit permissions unless those permissions also specify inheritance (for Files, Folders and/or Subfolders). You can limit inheritance to just a single folder (container) or allow it to apply to all levels below that folder. Inheritance is one of the powerful security features of Windows. As a general rule you want to set the permissions at as high a level as possible in the directory "tree" to avoid having to change permissions on a lot of individual folders or files. Most folders and files should inherit their permissions. I generally try to avoid denying permissions because no security entries (on the same object) can grant the permission back again if it's denied. If I don't want a permission granted, I usually turn off inheritance of permissions and then set the permissions to grant what I want. Be careful when changing permissions. You normally should give SYSTEM full control of files and folders, and also Administrators. Don't deny permissions to SYSTEM unless you are sure that the folders and files are not required for booting or logging in to Windows. Folders that are part of Windows should always have permission for SYSTEM and ADMINISTRATORS. That includes "WINDOWS", "Documents and Settings", "Program Files" and "System Volume Information". Also, hard disk C: should allow the same access as the Windows related folders. The Execute permission is confusing because it means different things for files and folders. Applying to files (even if set on the parent folder and inherited by files) it gives permission to execute the file as a program. Applying to folders it gives permission to access files and folders underneath that folder. That is called "traversal". It does not grant or deny permission to "see" the list of files and folders in the directory. Just granting Execute permission to a folder only allows accessing the files and folders if you already know the names. You can't do things like wildcard searches or opens. Windows policies normally allow EVERYONE to "Bypass traverse checking". That means the "Execute" permission applying to folders (but not applying to files) is ignored. The read permission for folders allows you to "see" the list of files in the folder, but not necessarily access any of the files. You have to have "Execute" permission (traversal) for the folder to access the files. The write permission for folders allows you to create new folders or files within the folder. Read and Write for files control access to the data in the file. Delete permissions apply to either a folder or a file. Being able to delete a folder does not necessarily allow you to delete things inside (below) the folder. You can always delete the WHOLE folder and ALL OF its contents by deleting the folder. You might not be able to delete just part of the contents if those contents don't have delete permission. The help in Windows is actually pretty good for security permissions. Click the question mark in the dialog for setting security, and then click on some of the links in the help text to get other information |