Taking ownership of a file doesn’t give you access, yet

A colleague of mine accidentally ran a command from an elevated command prompt rather than a normal unelevated command prompt. By default, files created from an elevated command prompt are owned by the Administrators group, on the theory that you are doing work in the elevated command prompt in your rôle as the system administrator, so the things you are doing are done on behalf of all the administrators of the system. (If you don't like this you can use the Default owner for objects created by members of the Administrators group policy to change the default.)

My colleague attempted to repair the damage by taking ownership of all the files back: From the root of the directory tree of files that got created with the wrong owner, he ran takeown /f . /r to take them back. (You naturally have to do this from an elevated command prompt. Since you left off the /A flag, this assigns ownership to you personally, rather than to the administrators group.)

"I can confirm that I am the owner by using the dir /q command, but I still don't have access. What gives?"

Having ownership of a file does not automatically grant you full access. Users always have WRITE_DAC permission on objects they own, but that's all. If you want more, you need to leverage WRITE_DAC into full access.

Fortunately, leveraging WRITE_DAC into full access is easy, because WRITE_DAC gives you permission to change permissions, so you can just change the permission to grant yourself full access:

cacls /e /g domain\user:F
Comments (27)
  1. anonymouscommenter says:

    Ah yes the old chestnut. Incidentally it's true on UNIX too but you rarely get to see it.

  2. anonymouscommenter says:

    Joshua: Well, on UNIX with traditional permissions rather than ACLs, you'd just inherit whatever permissions the previous owner had, as far as I can remember (and I'm not in a position to double check right now).

  3. anonymouscommenter says:

    Unix permissions are easy.   chmod 777 *   sorts out most problems.  

  4. anonymouscommenter says:

    chmod 777 * "sorts out most problems" at the expense of letting EVERYONE read, write, and execute the file(s).  Is that REALLY the best answer to a problem?  

    Why have a file permission system at all?

  5. anonymouscommenter says:

    chmod 777 can create problems, since it turns off setuid bits etc.  Run that as root in (/usr)/bin and you're screwed

  6. Kirillenseer says:

    Well, owernship doesn't mean being able to access the contents, it means the ability to give oneself the right to access the contents. It's like being an administrator on Windows in general: you don't have privileges to do anything you want, you "only" have privileges to grant yourself all privileges. This is a stark contrast to the Unix way of doing things and I frankly prefer the Windows way.

  7. anonymouscommenter says:

    OK, so we know the story behind "coördinate". What's the story behind "rôle"?

  8. anonymouscommenter says:

    Inquiring minds also wonder why Raymond's suggesting people use cacls instead of icacls.

    [Because I'm old and learned this stuff before icacls was invented. So, yeah, use icacls. -Raymond]
  9. henke37 says:

    Note that there may be an existing rule giving* the owner access. So in that case, taking ownership really does grant you new permissions.

    *And denying.

  10. anonymouscommenter says:

    @Dirk gently: TL;DR: role is a word that came from Old French, where it had a circumflex It's so thoroughly adopted into English that the circumflex indicates pretension and not distinction.

  11. anonymouscommenter says:

    Clearly the chmod 777 * post was tongue-in-cheek.

  12. anonymouscommenter says:

    This is one of the ways in which Windows NT is simply better than UNIX.  The way ACLs work in NT is vastly superior to the very limited archaic UNIX model, or even the updated POSIX ACL model that isn't used very often.

    The best thing about ACLs in NT is that SIDs are similar to GUIDs – they have enterprise-wide uniqueness.  A permission entry refers to the same user or group regardless of the machine on which it resides (unless it's a well-known RID that's referring to the local machine).  Thus, unlike in a UNIX OS, you can easily take drives and move them to different servers without the permissions getting reinterpreted with the wrong user IDs.

  13. anonymouscommenter says:

    I thought a circumflex in french indicated that there was once an "s". But apparently there are a few exceptions to this rule where it was once another consonant, and "rôle" used to be "rolle".

  14. Dave Bacher says:

    The real question I have on this one is — why require two commands for what is probably the most common case?

    chmod 777 — might as well just use MSDos, or Windows 9x :P

    Anyway — the thing here as I see it is this.  Every time I have ever used takeown (through command line or through Explorer) it has been immediately followed by setting permissions so I can do something, typically so that I can remove whatever file(s) are involved.  And so realistically, merging those two things into one step would be orders of magnitude better for a situation where you're already ticked off at Microsoft.


  15. jader3rd says:

    This has caused no end of grief as part of the Windows 8.1 upgrade. I know for myself that some files in my %LocalAppData% folder to become system files during the upgrade and that caused some background services to spin like crazy. Nearly every family member of mine also had the HKCU tree get 'corrupted' like this, resulting in their user not being able to modify certain keys. The kicker was WinRT apps that they had previously launched. After updating to 8.1 they couldn't launch apps that they had used, but could launch apps that they had never used before. It was good times hunting that down.

  16. Nico says:

    chmod 777 * is clearly a bad idea.

    chmod a+wrx * is a lot safer.

  17. Malcolm says:

    Dave Bacher: If you want to do both, use Helge Klein's SetACL.

    SetACL even lets you *set* ownership of a file but leaves the DACL intact. Something no Microsoft tool dares to do … :) You are still stuck if you have no access to the file … but you can back up the ownership, set yourself as owner (thus giving you implicit WRITE_DAC access), add whatever you want to the DACL, and then restore the ownership. Very neat :)

  18. anonymouscommenter says:

    @Myria Superior for some cases, perhaps, but for casual users, that "superiority" comes at unnecessary complexity.  Replacing your home computer and need to transfer a drive?  All of your user's files are owned by a different SID, which you can't replicate.

    NT ACLs are rather confusing, which in general is bad for security, because it's harder to get them right.  The Unix ones might be inferior, but I think they're usually a better compromise between security and ease-of-use.

  19. anonymouscommenter says:

    @Myria Fully agree that the Windows ACLs are much more superior than their counterparts in Unix. However what I find weird is that most Windows users don't use it properly to protect their system files in C: drive. Rather they tend to rely on anti-virus software (which almost hog CPU/disk) for protection. It is very sad that Windows had this nice security feature right from the time of NT/2000 but perhaps it did not advertise this feature well enough to a common windows desktop user. In fact most windows users almost always work as "Administrators" or "Power Users" (in spite of the "Run As" feature which allows privilege elevation on need basis).

  20. anonymouscommenter says:

    Is there a good book / reference for learning about windows ACLs? All I can find is MSDN, and that is mostly useful as a reference and not for learning.

  21. anonymouscommenter says:

    If coördinate makes me want to say "co-ERR-dinate", rôle makes me want to say /ʁol/.

  22. poizan42: It's any removed character(s), as far as I know.

  23. AndyCadley says:

    @James: The Unix way doesn't necessarily help in that case either, you might get lucky but you're equally likely to accidentally end up granting another user access to something they shouldn't have. Not great from a security standpoint.

    And I'm not sure I'd necessarily consider them simpler either, there are a whole raft of gotchas that come from "other" permissions not to mention weirdness from setuid, setgid and sticky bits.

  24. anonymouscommenter says:

    Yo dawg, I heard you like permissions, so we gave you permission to give yourself permissions.

  25. anonymouscommenter says:

    @Malcolm: I obviously need to look into this SetACL utility, particularly when I need to set permissions in order to have permission to traverse the directory tree to take ownership of it. The best Explorer can do is to reset the permissions on the entire subtree as it takes ownership, but that's not always what I want.

    This is where the Windows NT ACL model failed me; because changes to inherited permissions weren't automatic, I couldn't simply take ownership of the root of the subtree and give myself permissions at the root. Instead, I had to take ownership of the root, then give myself permissions to the root, then take ownership of all the subfolders (but not the files within those folders because I didn't have permission to those folders yet), then give myself permissions to the subfolders, then take ownership, then give myself permissions, etc, etc.

  26. Malcolm says:

    Neil: That's the beauty of SetACL – although when hundreds of thousands of files are involved, it can be slow. If doing a CIFS share, choose where you do it from wisely – use the fastest and nearest network connection you can get. Do it locally on the server if possible (I couldn't, because it was a non-Windows NAS box I was doing it to…).

    There's an entry in the FAQ on how to do it, written by someone called … err … Malcolm ;) The bit about CREATOR OWNER turns out to be a non-problem; it isn't reassigned to the new owner when ownership changes. Same applies to any CREATOR GROUP permissions.

    Another odd perversion of the permissions system I once played with was 'How do you identify which Administrator created a file?' Well … there is (as pointed out) a policy setting which will make the original user own files. But what if you don't want to do that, because *not* having files owned by Administrators causes a whole set of other problems?

    1. For user XYZ, create a group and call it AdminUser:XYZ.

    2. Assign this as the primary group for user XYZ.

    3. Set an inheritable *audit* access control entry for CREATOR GROUP. You can choose what to set it on. Change Permissions and Take Ownership would be two great candidates.  Something that doesn't happen a lot, unless you want to audit a lot of stuff anyway… in which case you'll have separate audit ACEs that cover that.

    Whenever an ordinary user creates a file/folder in that directory, the file will inherit an audit ACE for 'Domain users'. That's OK, because you can tell from the NT ownwership who it was.

    But if an admin user creates a file, the file ownership is 'Administrators'. However, your audit ACL will now have an entry for … AdminUser:XYZ. Additionally, a new folder still inherits the CREATOR GROUP audit ACE to pass it on to other folders/files that are created underneath it …

    I never bothered to try putting this in place as we instead limited the number of people with full admin rights over our NAS storage … but someone else might like to pick up the idea and run with it.

    Beware: This can cause the Domain Admins/Domain Users group to grow large, causing replication issues… and if you're stuck with a Windows 2000 level domain (I hope not!) there's a limit of 5000 users a group. No doubt there are other reasons this is a bad idea … :D

Comments are closed.

Skip to main content