Taking Ownership Fails With UNC Path, Works Locally!?! Why?

  • Security
  • Published Jul 28, 2010 Updated Jul 14, 2019

Here is an interesting tidbit related to Windows security:

  1. Create a test file share, e.g. C:\temp\test, and share it with full permissions for everyone (share, not NTFS permissions) as “test”
  2. Create the following directory hierarchy below the share: C:\temp\test\1\2\3\4
  3. Assign ownership of the four folders 1, 2, 3 and 4 to any user (but do not use your own account, just anyone else’s)
  4. Set permissions on 1, 2, 3 and 4 that only the user from the previous step has full access, nobody else, not even the SYSTEM
  5. Now try to use SetACL to change the owner of directory “4” over the network (SetACL uses backup and restore privileges so this should be no problem) by issuing the following command locally:
    setacl -on \localhost\test\1\2\3\4 -ot file -actn setowner -ownr n:domain\administrator
  6. SetACL will fail with access denied (full message: “ERROR: Writing SD to <\?\UNC\localhost\test\1\2\3\4> failed with: Access is denied.”)
  7. Now issue the same command, but instead of using a UNC path use the local drive letter:
    setacl -on c:\temp\test\1\2\3\4 -ot file -actn setowner -ownr n:domain\administrator
  8. That works!

Why is this so? I have no clue.

This is also documented in the FAQ for SetACL.

Comments

Related Posts

Latest Posts

Filebrowser to Be Archived. Migrate to a Modern Alternative: Sambee

Filebrowser to Be Archived. Migrate to a Modern Alternative: Sambee
Filebrowser is being archived. As the author writes, the codebase dates back to when he was but 15 years old. Having created such a popular file management tool is a more than impressive achievement for anyone, let alone a teenager. However, when it comes to security and reliability, Filebrowser seems to be built on a less than ideal foundation, so much so that the author states:
Home Automation, Networking & Self-Hosting