The following code creates a folder named “JWSCLTest” and applies a DACL that allows full control to everyone. The folder will inherit its security settings to child folders and files (check the afXXX flags).

const JWSCLTestFolder = 'JWSCLTestFolder';

var
  SD : TJwSecurityDescriptor;
  pSA : PSecurityAttributes;
begin
  JwInitWellKnownSIDs;

  SD := TJwSecurityDescriptor.Create;
  try
    SD.DACL.Add(TJwDiscretionaryAccessControlEntryAllow.Create(nil,
      [afContainerInheritAce, afObjectInheritAce], FILE_ALL_ACCESS, JwWorldSID));

    pSA := SD.Create_SA();
    try
      Win32Check(CreateDirectory(JWSCLTestFolder, pSA));
    finally
      SD.Free_SA(pSA); //remember to free pointer
    end;
  finally
    SD.Free;
  end;
end.

CreateDirectory receives a security attributes structure that is applied to the folder directly. However, in this way the parent security descriptor is not inherited to our folder. This is called a protected DACL because the inheritance flow is stopped. So we get a folder with only one Access Control Entry (ACE) : Everyone (aka World SID). To remedy that we can copy the ACEs from the parent folder to our own folder:

procedure MergeParentDACL(const Location : String; TargetSD : TJwSecurityDescriptor);
var DirSD : TJwSecureFileObject;
begin
  DirSD := TJwSecureFileObject.Create(Location);
  try
    TargetSD.DACL.AddACEs(DirSD.DACL);
  finally
    DirSD.Free;
  end;
end;

var
  DirSD : TJwSecureFileObject;

  SD, SD2 : TJwSecurityDescriptor;
  pSA : PSecurityAttributes;
begin
  JwInitWellKnownSIDs;

  SD := TJwSecurityDescriptor.Create;

  try
    SD.DACL.Add(TJwDiscretionaryAccessControlEntryAllow.Create(nil,
      [afContainerInheritAce, afObjectInheritAce], FILE_ALL_ACCESS, JwWorldSID));

    MergeParentDACL('.', SD);

    pSA := SD.Create_SA();
    try
      Win32Check(CreateDirectory(JWSCLTestFolder, pSA));
    finally
      SD.Free_SA(pSA);
    end;
  finally
    SD.Free;
  end;
end.

The function MergeParentDACL receives the location of the parent folder and retrieves its security settings. Then its DACL is copied to the target security descriptor. JWSCL with TargetSD.DACL.AddACEs makes sure that the order of the ACEs are still correct (first deny then allow entries) by moving them accordingly.

In addition, there is a second, much easier way to achieve the same result.

var
  SD : TJwSecurityDescriptor;
  DirSD : TJwSecureFileObject;
begin
  JwInitWellKnownSIDs;

  Win32Check(CreateDirectory(JWSCLTestFolder, nil));

  DirSD := TJwSecureFileObject.Create(JWSCLTestFolder);
  try
    SD := DirSD.GetSecurityDescriptor([siDaclSecurityInformation]);
    try
      SD.DACL.Add(TJwDiscretionaryAccessControlEntryAllow.Create(nil,
        [afContainerInheritAce, afObjectInheritAce], FILE_ALL_ACCESS, JwWorldSID));

      DirSD.SetSecurityDescriptor(SD, [siDaclSecurityInformation]);
    finally
      SD.Free;
    end;
  finally
    DirSD.Free;
  end;

In this way we didn’t set the security descriptor directly when the folder was created. Nevertheless we get a combination of inheritace ACEs plus the explicit one (JwWorldSID).

Note

It is always a good idea to check whether SD.DACL (in above codes) is nil and if so ignore it or create a new and empty one to be used instead. It is always possible that a file or folder comes with a nil DACL which means either no access at all (flag DACLpresent) or everyone has full access (flag DACLpresent not available).

I used the following JEDI units:

uses
  JwaWindows,

  JwsclDescriptor,
  JwsclTypes,
  JwsclConstants,
  JwsclKnownSid,
  JwsclAcl,
  JwsclMapping,
  JwsclSecureObjects,
  JwsclSid,

Last time we used the SecurityAttribute parameter in CreateFile to change the security descriptor of the newly created file. However this approach did not add inherited access control elements from the parent folder. We are about to change that.

Filesystem and Registry-key inheritance is implemented since Windows 2000 and also can be added to Windows NT 4 by installing an update. It is a really convenient way to set security over many files in a complex folder tree.

So what did we last time?

This code assigns a simple security descriptor. In my tests there was no way to let CreateFile add the inherited elements to the DACL. Luckily there are several ways to do so.

1. Get the inherited access elements from the parent and add them to our DACL by hand
2. Let the system handle inheritance
3. Do the second way much faster

1. Get the inherited access elements from the parent and add them to our DACL by hand

The first choice needs a lot of work to do. First we need all the inheritable access control elements from the parent folders. This would become very nasty if we had to recursively go up to all parent folders to get the elements. However we are lucky because all inherited ACEs are always available through the direct parent container (if they are not blocked).
Because I will need more time to describe this approach. I’m going to skip this part for now and discuss it in a separate blog entry.

2. Let the system handle inheritance

JWSCL supports inheritance of file, folder and registry keys with the classes TJwSecureFileObject and TJwSecureRegistryKey. We are going to use only TJwSecureFileObject for our task. However changing permissons and inheritance of a registry key is straight forward and is much the same job as it is with files and folders.

TJwSecureFileObject offers three ways to adapt security of a file or folder. You can use a file/folder handle (retrieved by CreateFile), a file or folder name or you use the VCL class TFileStream. However the last variant has some disadvantages like not being able to work with folders.

TJwSecureFileObject retrieves the DACL of the file after newly created file was opened. The method SetDACL sets the DACL back but also removes the protection flag from security descriptor control. Thus all the inherited access elements flow to the file’s access control list.

3. Do the second way which is much less to write

TJwSecureFileObject offers class methods to act with file or folders much faster. We can either restore the inheritance flow by using the file/folder name…

or reestablish the inheritance flow by using a file handle.

You can use one way or the other.

Tell me how you liked this blog entry by adding a comment.

Cite:
Inherited permissions on an object are established when it is created. Once the object has been created, you can change the permissions of the parent and it won’t have any effect unless you explicitly ask for the inheritable properties to be re-propagated to the child objects.

Read more about it at Raymond’s blog.