none
一个搜遍网络也没能弄清的NTFS文件权限问题,请教大侠! RRS feed

  • 问题

  • 这个问就是:“写入数据”与“附加数据”的区别。

    尽管下面粘贴来的有关“写入数据”与“附加数据”两个权限的文字对此做了一些解释,但本人在应用中还是没有搞清两者的区别。哪位大侠能够详细例举讲讲,比如以word文档和文本文件来讲讲,最好不是想当然,而是能经得起测试:
    。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

    ⑸创建文件/写入数据(Create Files/Write Data):
      该权限允许用户在文件夹中创建新文件,也允许将数据写入现有文件并覆盖现有文件中的数据;
    ⑹创建文件夹/附加数据(Create Folder/Append Data):
      该权限允许用户在文件夹中创建新文件夹或允许用户在现有文件的末尾添加数据,但不能对文件现有的数据进行覆盖、修改,也不能删除数据;
    。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。



    2010年1月26日 7:59

全部回复

  • 不知哪位大侠能用实例来进行说明? 

          本人觉得对“写入数据”与“附加数据”两个权限的区别如果能用具体的实例来进行说明是再好不过的。我在网上搜了一下,竟没发现对这两个概念区别与应用的详细阐释,都是微软官方那寥寥数字的解释。

        本人谈一下自已的浅陋想法,请大侠们不要见笑,多多斧正:

           本人建一个txt文件A,文件内容是abcde(仅五个字母,甭见笑,只是为了方便)。那么是不是我就可以这样理解:1、若我将abcde改为ab1111cde我便是对此文本文件进行了“写入数据”的操作;2、若我在abcde后回车并输入1111,我便是对此文本文件进行了所谓的“附加数据”的操作。 不知本人这样的想法对不对?
         为了验证以上猜想对不对,我对此文本文件设置了“写入数据”的拒绝权限以及“附加数据”的允许权限。结果,在我将abcde改为abcde1111进行保存时,系统提示该操作被拒绝。这又是为什么呢? 如果这样的操作属于“写入数据”的操作而不是“附加数据”的操作,哪么,什么样的操作属于“附加数据”的操作呢?

           本菜鸟恳请大侠们还是能举几个“写入数据”与“附加数据”操作实例来说一说两者的区别!

            如果再拿一个excel数据表来说,是不是给这个数据表中间插入几行数据或改写几个单元格就是“写入数据”,而仅仅是在数据表末尾补加几行数据就是“附加数据”呢?
               先谢谢各位了!
    对于能帮上忙的大侠,本人将对其各类主题贴顶十次,以示感谢!
    2010年1月26日 8:01
  • 这问题,微软官网咋都不能给个很好的回复!?

    高手不屑,还是坛中乏人。

    2010年1月27日 3:12
  • 再顶一下

    2010年1月28日 10:30
  • 你好,

    两者的一个重要区别在于是创建文和文件夹时的权限

    A 创建文件/写入数据(Create Files/Write Data)

    B 创建文件夹/附加数据(Create Folder/Append Data)

    在同一文件夹下,deny A不能创建文件但可以创建文件夹,deny B不能创建文件夹但可以创建文件

    至于对现有存在的文件,无论Write和Append, 作用都一样,任何一个deny了对现有文件都写不进去了

    可以参考

    http://xato.com/hardening/pointless-permissions






    黄俊贤 Tommy Huang

    TechNet中文论坛ID j-mcgrady
    WinOS社区ID VirtualTom
    http://blogs.itecn.net/blogs/virtualtom
    一起共同学习和交流,共同进步
    2010年1月28日 13:58
    版主
  • Pointless Permissions

    One thing I have always liked about NTFS security is the fine-grained control you have over file permissions. But this power comes at a price—you must understand a whole new world of acronyms, confusing metaphors, and expanded definition of words such as principal, trustee, and inheritance. To fully take advantage of file permissions you need to understand how the whole thing works and delve into the lower levels where there is no pretty user interface and no cushion between you and the inner working of windows. You know you are close to understanding NTFS file permissions when you stop talking about files and folders and instead refer to objects and containers.

    So over the years I spent the time to truly understand the inner workings of NTFS permissions. I spent the time to learn about ACLs, ACEs, DACLs, SACLs, SIDs, RIDs, inheritance, protected ACL’s, trust, and impersonation. I can set an ACL purely through SDDL and I hardly have to refer to my cheat sheets anymore.

    And what did I gain from all this time and research? Nothing. When I set file permissions now I really only care about four basic things: read, write, execute, and delete.

    There are several reasons for this. For one, I learned the importance of simplicity. NTFS permissions are so complex that so far no one has come up with a good way to even visualize them. Sure, we have the security settings dialog box but you can’t just glance at a directory or directory tree and quickly see who can do what.

    But the main reason I have abandoned complex permissions is because most of the time they just don’t work the way you think they would.

    Take the Delete permission for example. Many Windows administrators know that you can Deny Delete on a file and yet you can still delete it. Why is this? Because the parent folder has a permission called Delete Child that lets you delete files even if you specifically protect a file from being deleted. Now I could write pages of reasons on why this is lame, but I’ll save that for another time. What it comes down to is that in order to prevent something from being deleted you also have to tell the parent folder to not allow child files to be deleted.

    Essentially, the Delete Child permission breaks all the rules of NTFS permission inheritance. An allow overrides a deny and a parent object’s ACL overrides a child object’s ACL—even if the child is protected from inheriting from a parent.

    But don’t make the mistake of thinking that denying child deletion on a parent actually prevents child deletion. It just prevents the overriding of the delete permissions on any child that denies delete permissions. Although Microsoft claims that this behavior is for Posix compliance, I seriously question the need for this permission at all. And if Posix compliance is so important, why is there still case insensitivity in file names, drive letters in the file namespace, no concept of setuid, ELF vs PE executables, and inconsistent traverse checking?

    It doesn’t stop there. Another problem is the Read Attributes permission. This permission is ignored if the parent folder allows listing a directory. Yes, this does makes sense—if you can list a directory you should be able to list the attributes for files in that directory. Again, it makes me wonder why even have this permission? The only time you would actually use it is when you deny a user from listing a directory and don’t want them to be able to see a file’s attributes if they happen to already know a file name in that directory, and have read access to that file. Certainly this type of control could be shared between the List Directory and Read permissions.

    Also useless are the Write Data and Append Data permissions. In theory these could be quite useful but most software—including windows—doesn’t get that specific when requesting write access. Most code simply requests the generic Write permission which includes both write and append.

    Let me illustrate this. Create a file named test.txt and deny Append Data, allowing all other permissions. Now try this at a command prompt:

    C:\>echo test >> test.txt
    Access is denied.
    C:\>echo test > test.txt
    Access is denied.

    Do you see what happened? Denying the ability to append data did work, but you also denied the ability to write data. Now try the reverse and allow everything but deny Write Data. Run the commands above again and you will get the same result. In other words in most cases, the Append Data and Write Data permissions will behave the same. It all depends on how the code requests access to the file. If the code requests the generic Write permission, it won’t distinguish between append or write. This is important because if the code does use the generic Write permission, denying either append or write will deny the entire operation so it’s best to never use those anyway. The Take Ownership permission is quite useless because that is controlled by system privileges anyway. You cannot deny the Take Ownership permission for Administrators or users with the Restore Files and Directories system privilege, such as Backup Operators. This is because these users have the system privilege Take ownership of files or other objects. Technically you could take away this right from Administrators, but an Administrator can put it right back again. If you think about it, this permission is mostly pointless because by default no one can take ownership of a file unless they are already an Administrator or Backup Operator. And if they are already in one of those groups, this permission has no effect anyway. The only situation where you could use this permission is if a user or group was not a member of the Administrators group, did not have the Restore Files and Directories system privilege, yet did have the Take ownership of files or other objects privilege, but you wanted to deny them the ability to take ownership of a specific set of files. In that case you would need this permission on the specific set of files, but what have you really gained?Read Permissions and Change Permissions are kind of strange. They do not apply to the file’s owner, even if you explicitly deny that these permissions. Therefore, these permissions also do not apply to any user with the Take ownership of files or other objects privilege. If you want to deny Read Permissions or Change Permissions, you must also deny the ability to Take Ownership.

    Finally, in most cases don’t bother changing Traverse Folder permissions, because by default every user on the system is given the Bypass Traverse Checking user privilege. Microsoft has long recommended not enforcing traverse checking because it has been known to cause problems with applications that don’t properly handle directory traversal errors.

    The Read Extended Attributes and Write Extended Attributes permissions have no effect if the programmer requests the generic Read and Write permissions. In fact, you need to be careful with these because denying either one could cause the generic Read and Write access to fail.

    So again, what have I learned from all this research? Don’t even bother with anything more than read, write, execute and delete.

    Oh and don’t forget, denying Read to a file doesn’t prevent someone from being able to execute it

    2010年2月1日 12:00
  • http://technet.microsoft.com/zh-cn/library/cc732880%28WS.10%29.aspx看了这个你应该贵NTFS各个权限会有清楚的了解。
    因为我是笨笨的所以我是笨笨ONE,当然我的身边还有个可爱的笨笨TWO。
    2010年2月3日 3:50
    版主