File permissions: Executable but not moveable?


  1. Posts : 2
    Windows 7 Ultimate 64-bit
       #1

    File permissions: Executable but not moveable?


    Hello everyone,

    trying to make a file unable to be deleted or moved, but still executable, I was changing the file permissions and didn't manage to make it work.

    Allowed: Execute File, Read Data, Read Extended
    Denied: Write Attributes, Write Extended, Write Data, Append Data, Delete

    When I do that, I can still delete and move it, unless I deny full control or remove all allowed. Do you have an idea how to make it work?

    Thanks in advance :)
      My Computer


  2. Posts : 721
    Windows 10, Windows 8.1 Pro, Windows 7 Professional, OS X El Capitan
       #2

    Hello Dimali,

    You may realise this already, but there is a strong relationship between deleting and moving in terms of NTFS permissions. I want to make it very clear to readers that if one is asking to deny a user move capabilities on a certain file system object, essentially, they are asking how to deny that user from deleting the object, as a move is a combination of the copy and delete operations. If you can’t delete, you can’t move and vice versa.

    dimali said:
    I was changing the file permissions and didn't manage to make it work.
    I'm glad you gave it a go first. Dimali, you’re close to the solution, you just need to add one more access right...

    The Delete access right is a bit of a weird one. Simply checking this option for a file system object is usually not enough to prevent the target trustee from deleting the object, on its own. For the denied Delete rule to be effective, the object must also include a rule that specifies a deny of the access right Delete subfolders and files. Only when an object has both Delete and Delete subfolders and files rights denied, the target trustee will then not be able to delete the object.

    This behaviour makes sense; a delete operation is an operation performed on a folder, not a file.

    “But files don’t offer a checkable Delete subfolders and files right—only folders have them?”
    Correct. This means if you wish to revoke one’s ability to delete a file, it’s two new ACEs you’ll have to create: one on the file (check the Delete access right) and one on the folder containing that file (check the Delete subfolders and files access right). It’s worth noting that the file does not necessarily have to inherit the latter rule: only, the Delete subfolders and files access rule must be in effect on the folder containing the object... except when dealing with folders themselves. If it is instead a folder you wish to prevent deletion of, simply deny both the Delete and Delete subfolders and file access rights on that one folder to achieve the same effect.

    “If preventing deletion of a file system object involves denying the Delete and Delete subfolders and file rights, why can’t I ever delete an object denied Full Control?”
    This is an exception. Being denied Full Control is not the same as being denied every other access right. If you are denied Full Control, or if you have zero ‘allow’ type rules on a file system object, immediately we can conclude that your user cannot do anything with or to that object, including deletion.


    TL;DR
    To prevent a user having delete access to a file system object, on the object, create a rule which denies the Delete access right, then on the folder containing that object, create a rule that denies the Delete subfolders and files right.
    Last edited by Pyprohly; 27 Jun 2016 at 08:12.
      My Computer


  3. Posts : 2
    Windows 7 Ultimate 64-bit
    Thread Starter
       #3

    Excellent! It worked like a charm.
    Thank You a lot, Pyprohly.
      My Computer


 

  Related Discussions
Our Sites
Site Links
About Us
Windows 7 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 7" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 18:05.
Find Us