How do I create a directory where people can create subdirectories but cannot mess with those created by other users?


A customer was having trouble setting up security for a new file share for which they wanted a particular usage model:

What we would like is for everybody to be able to create new files and folders on the share but not overwrite existing content. We can't find the correct set of ACLs that give us what we want. We found "Create Folders / Append Data", which sounds like it lets you create folders and append to existing files on the share, but it doesn't let you create files. Is that correct? What's more, when we tried it, it didn't seem to do what it says on the tin. We can create folders, and we can create empty files, but we are unable to write any content into those files. Maybe the permissions we are setting up don't make sense? Can you suggest a security configuration that gives us what we want?

"Create Folders / Append Data" access is one of the many two-headed permissions in file system security. It means "If applied to a folder, you can create folders. If applied to a file, you can append data." That's what the slash is trying to tell you.

What you can do is set "Create Folders / Append Data" on the root folder, but mark it is non-inheritable. This means that users can create folders in the root, but since it doesn't inherit, they will not be able to create folders inside any folders they create, nor will they be able to append to any files they create. (On the other hand, that seems to result in the situation described above, where you can create a file but you can't write anything to it, because writing to an empty file is equivalent to appending.)

But let's suppose that the customer's "not overwrite existing content" really means "not overwrite existing content created by other users". In other words, we want to let users create new content, and they can do whatever they want to the content they created, but they can't mess with content created by others.

As noted by my colleague Pavel Lebedinsky some time ago, the Windows temp directory is set up very similar to what you want.

C:\Windows>cacls temp
                BUILTIN\Users:(CI)(special access:)
                                  SYNCHRONIZE
                                  FILE_WRITE_DATA
                                  FILE_APPEND_DATA
                                  FILE_EXECUTE
 
                BUILTIN\Administrators:F
                BUILTIN\Administrators:(OI)(CI)(IO)F
                NT AUTHORITY\SYSTEM:F
                NT AUTHORITY\SYSTEM:(OI)(CI)(IO)F
                CREATOR OWNER:(OI)(CI)(IO)F

Administrators and SYSTEM get full access to everything, but that's not unusual. The interesting ACEs are the ones for Users and CREATOR OWNER.

The dual-headed-ness of many file system access mask values makes the output a little harder to understand, because FILE_WRITE_DATA means different things depending on whether you apply it to a file or to a folder. Let's see what we can figure out.

The Users ACE is marked Container Inherit (CI) which means that it applies to this folder and subfolders, but not to files. FILE_WRITE_DATA applied to a folder means FILE_ADD_FILE, so users can create files in this folder or any subfolders. FILE_APPEND_DATA applied to a folder means FILE_ADD_SUBDIRECTORY, so users can create subdirectories in this folder or any subfolders. And FILE_EXECUTE applied to a folder means FILE_TRAVERSE, so users can traverse through this folder any subfolders.

Recall that CREATOR OWNER is a placeholder ACE. Nobody actually has CREATOR OWNER; rather, it is a template that gets applied to newly-created objects. Therefore, the CREATOR OWNER ACE gets applied to files and folders that users create, and the user who created the file or folder is inserted as the owner. Here, the ACE is saying that users have full control over any folders or files that they create.

The security settings for the Windows temp directory are a good start for fiddling around with usage patterns like the one the customer is looking for. In fact, it may already be what the customer wants.

The customer thanked us for the information.

Comments (11)
  1. jspenguin says:

    Sounds like they want the equivalent of the "sticky" bit from UNIX. Linux has had full ACLs on most filesystems for years now, but it's amazing what could be accomplished with just a few permission bits.

  2. 12BitSlab says:

    Raymond, thanks is this is very timely. I passed this blog post on to our internal support team (i.e., sys admins) because they are dealing with something similar right now. Again, thanks!

  3. Ben Voigt says:

    Attempting to translate "it is a template that gets applied to newly-created objects" into real-world implications...

    This means that exercising the "Take Ownership" action will not actually grant privileges associated with CREATOR/OWNER to the newly designated owner; those remain with the original (at the time of file creation) owner. Correct?

    1. alegr1 says:

      "Take ownership" doesn't modify the ACL, it just changes the owner. CREATOR-OWNER permissions are set up to apply to the contained objects. If you check the permissions info, the files actually lose it, they have an entry for an actual user. Thus, the new owner will not automatically have the access.

      1. Ben Voigt says:

        @alegr1 Well, changing a user's (or his token's, in the case of UAC) group membership doesn't modify ACLs either, but it certainly does affect the effective permissions. It's good to know that the change in owner doesn't impact permission evaluation.

  4. I remember studying all this 10 years ago during my MCSE training... Lots of things have changed but not these.

  5. Medinoc says:

    If I got it right, "Creator Owner" permissions should always be marked "Inherit Only", correct?

    1. dave says:

      Doesn't really matter, since as an ACE applying to 'this object', it will never be matched against an accessor.
      But yes, for clarity make it inherit-only.

  6. MarcK4096 says:

    CREATOR OWNER has been a very helpful. I was lucky enough to encounter a sample set up by another admin years ago. It's very handy for allowing user profile folders with the proper permissions to be created by the user during the first logon.

    1. Malcolm says:

      CREATOR GROUP is another handy one if you're willing to go out on a limb and change a user's primary group. I came up with an idea many years ago to create a unique group per user for all our admin accounts, make it the primary group for each admin user, and then assign an audit ACL, from the top down, to everything on the file server and have the audit ACL set to CREATOR GROUP on an obscure operation that's likely to rarely be used (such as failure to take ownership). Why?

      Well, suppose you have a non-Windows system, like a NetApp filer, and therefore cannot be assured that the group policy setting to make files written by Administrators group be owned by the individual account will be honoured in all circumstances. Or, you do not want to lose the flexibility that having the file owned by Administrators gives you, but want traceability too. Take three admin users ... Alice, Bob and Sue. You create an AdminUser:Alice, AdminUser:Bob, AdminUser:Sue group. Assign respectively as the primary group for Alice, Bob and Sue.

      When Alice, Bob and Sue create files/folders, they will be owned by Administrators. However, if you look at the security ACL it will have an entry created from your inheritable CREATOR GROUP ACE. When this ACL is written, it will have the primary group of each user and therefore tell you which one actually created it - while allowing you to retain the flexibility that ownership by Administrators was designed to give you in the first place.

      I tested this and it worked, but it never made it into production. Instead, we limited the number of admins. But someone out there might want to try it and see how it works. You may run into limits for direct membership of Domain Users if you have a large number of admins and an AD domain set at a very old functional level (like, Windows 2000 level). Caveat emptor ;)

      1. Malcolm says:

        I should also add: it doesn't need to be a security ACL but that way, it does not show up in discretionary ACLs, and also does not run the risk of disrupting normal file permissions. Say you set a CREATOR GROUP, full access, discretionary ACL and an ordinary user creates a folder? It suddenly has Domain Users FULL access...

Comments are closed.

Skip to main content