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,

I have added some comments to the source code itself so you can read a description directly in the code.

program GetEffectiveRightsFromAclTest;

uses
  JwaWindows,
  JwsclKnownSid,
  JwsclConstants,
  JwsclTypes,
  JwsclExceptions,
  JwsclSecureObjects,
  JwsclSid,
  JwsclDescriptor,
  JwsclAuthCtx,
  JwsclMapping,
  JwsclUtils,
  JwsclACL,

  Dialogs,
  SysUtils;

//computes granted access mask for a security descriptor and a SID
//An error is thrown by an exception - typical JWSCL
function GetEffectiveAccess(const SD : TJwSecurityDescriptor;
                            const Sid : TJwSecurityId) : DWORD;
var
  AuthRM : TJwAuthResourceManager;
  AuthCtx : TJwAuthContext;
  AuthReply : TJwAuthZAccessReply;
  Request : TJwAuthZAccessRequest;
begin
  //The following code uses the MS AuthZ API
  //JWSCL wraps the function calls
  AuthRM := TJwAuthResourceManager.Create('', [], nil, nil);
  try
    //Tell AuthZ to use a SID for access checking
    //We also could use a token and prevent the problem of
    // restricted Administrators in Vista/7
    AuthCtx := TJwAuthContext.CreateBySid(AuthRM, [], Sid, 0, nil);
    try
      //As documented AccessCheck returns a GrantedAccessMask
      //  when using MAXIMUM_ALLOWED
      Request := TJwAuthZAccessRequest.Create(MAXIMUM_ALLOWED,
                  JwNullSID, nil, nil, shOwned);
      try
        //does the access check using a generic mapping to file/folder
        AuthCtx.AccessCheck(0, Request, 0, SD, nil,
           TJwSecurityFileFolderMapping, AuthReply, nil);

        //return the granted access mask
        result := AuthReply.GrantedAccessMask[0];
      finally
        Request.Free;
      end;
    finally
      AuthCtx.Free;
    end;
  finally
    AuthRM.Free;
  end;
end;

//computes granted access mask for a file and username
//An error is thrown by an exception - typical JWSCL
function GetEffectiveAccessFromFile(
             const FileName,
             DomainName, UserName : string) : DWORD;
var
  F : TJwSecureFileObject;
  SD : TJwSecurityDescriptor;
  Flags : TJwSecurityInformationFlagSet;
  Sid : TJwSecurityId;
begin
  //Translate username and domainname into a SID
  //Throws an EJwsclWinCallFailedException if
  //  the username could not be translated
  Sid := TJwSecurityId.Create(DomainName, UserName);
  try
    F := TJwSecureFileObject.Create(FileName);
    try
      //adding siLabelSecurityInformation makes no sense
      //  since it cannot be checked against a simple SID
      Flags := [siOwnerSecurityInformation,
                siGroupSecurityInformation,
                siDaclSecurityInformation];

      //get the security descriptor (result is not cached)
      SD := F.GetSecurityDescriptor(Flags);
      try
        result := GetEffectiveAccess(SD, Sid);
      finally
        SD.Free;
      end;
    finally
      F.Free;
    end;
  finally
    Sid.Free;
  end;
end;

const
  Target = 'C:\Windows';
  UserName = 'Christian';

var AccessMask : TJwAccessMask;
begin
  JwInitWellKnownSIDs;

  AccessMask := GetEffectiveAccessFromFile(Target, '', UserName);
  ShowMessage(Format('File/Folder: %s'#13#10'User: %s'#13#10'%s',
    [Target,
     UserName,
     JwFormatAccessRights(AccessMask, FileFolderMapping)]));
end.

Be aware that the code does the same as GetEffectiveRightsFromAcl.

Restricted Administrator account in Vista/7

Also it does not take into account a restricted Vista account. The reason is that the privileges of an Administrator account are stripped away only when a user logs on. So the account management does not behave differently to Windows XP. Since we use an account name the function only finds the Administrators group in the membership list of the user. Thus we may see a fullly granted access mask as a result when using the function on e.g. the Windows folder.

Integrity Level in Vista/7

Of course, we cannot use the mandatory label (notice siLabelSecurityInformation) of a file or folder because the integrity level of the user is only known when she is logged on. Thus if a folder has a high integrity level, the function will still return full access control even if the user cannot write access (no-write-up) the folder when logged on.

Download

Download GetEffectiveRightsFromAclWithAuthZ.pas

WinAPI

uses
  SysUtils,
  //JwaWindows, //Use either JwaWindows or these JEDI headers:
  JwaWinBase,
  JwaWinType,
  JwaWinNT,
  JwaAclApi,
  JwaAccCtrl,
  JwaWinError,
  JwaSddl;

type
  TOwnerResult = (orNone, orName, orSID);

function GetFileOwner(const FileName: string;
  out Domain, Username: String): TOwnerResult;
var
  pSD: PSecurityDescriptor;
  dwOwnerNameSize, dwDomainNameSize: DWORD;
  pOwnerSID: PSID;
  pszOwnerName, pszDomainName: PChar;
  OwnerType: SID_NAME_USE;
  dwError : DWORD;
begin
  result := orNone;

  pSD := nil;
  dwError := GetNamedSecurityInfo(
     PChar(FileName),//__in       LPTSTR pObjectName,
     SE_FILE_OBJECT,//__in       SE_OBJECT_TYPE ObjectType,
     OWNER_SECURITY_INFORMATION,//__in       SECURITY_INFORMATION SecurityInfo,
     @pOwnerSID,//__out_opt  PSID *ppsidOwner,
     nil,//__out_opt  PSID *ppsidGroup,
     nil,//__out_opt  PACL *ppDacl,
     nil,//__out_opt  PACL *ppSacl,
     pSD//__out_opt  PSECURITY_DESCRIPTOR *ppSecurityDescriptor
   );
  if (dwError <> NOERROR) then
  begin
    SetLastError(dwError);
    RaiseLastOSError;
  end;

  //First get necessary memory size for Owner and Domain
  dwOwnerNameSize  := 0;
  dwDomainNameSize := 0;
  if not LookupAccountSID(nil, pOwnerSID, nil,
    dwOwnerNameSize, nil, dwDomainNameSize, OwnerType) then
  begin
    //Check for SIDs that are unknown on this local system
    if (GetLastError() = ERROR_NONE_MAPPED) then
    begin
      Win32Check(ConvertSidToStringSid(pOwnerSID, pszOwnerName));
      Domain := '';
      Username := pszOwnerName;
      LocalFree(HLOCAL(pszOwnerName));
      result := orSID;
      exit;
    end
    else
    //Any other error exits the function
    if (GetLastError() <> ERROR_INSUFFICIENT_BUFFER) then
      RaiseLastOsError;
  end;

  //Allocate memory for owner and domain
  //Take into account the size of a char type (like WideCHAR)
  GetMem(pszOwnerName, dwOwnerNameSize*sizeof(CHAR));
  try
    GetMem(pszDomainName, dwDomainNameSize*sizeof(CHAR));
    try
      //Retrieve name and domain
      Win32Check(LookupAccountSID(nil, pOwnerSID, pszOwnerName,
        dwOwnerNameSize, pszDomainName, dwDomainNameSize, OwnerType));

      result := orName;

      Domain   := pszDomainName;
      Username := pszOwnerName;
    finally
      FreeMem(pszDomainName);
    end;
  finally
    FreeMem(pszOwnerName);
  end;
end;

The function behaves the following:

• If an WinAPI error occurs the exception EOSError is thrown. You can retrieve the error value from its property Errorcode.
• If the user name could be retrieved the result value is orName and both parameter Domain and UserName contain a value. Otherwise the result is orSID and only UserName contains the User Security Identifier (e.g. S-1-5-21-564352346-2735467565-567745764-1001).

JWSCL

Of course, JWSCL wraps these function calls already. Thus the source size decreases rapidly. See another example here.
In JWSCL it is quite different to implement the function. However the behaviour is equal:

function JwsclGetFileOwner(const FileName: string;
  out Domain, Username: String): TOwnerResult;
var
  F : TJwSecureFileObject;
  Owner : TJwSecurityId;
begin
  F := TJwSecureFileObject.Create(FileName);
  try
    Owner := F.Owner; //Owner is cached/freed by TJwSecureFileObject
    try
      Domain := Owner.GetAccountDomainName();
      Username := Owner.GetAccountName();
      Result := orName;
    except
      on E : EJwsclWinCallFailedException do
      begin
        if E.LastError = ERROR_NONE_MAPPED then
        begin
          Domain := '';
          Username := Owner.StringSID;
          Result := orSID;
        end
        else
          raise;
      end;
    end;
  finally
    F.Free;
  end;
end;

In a next version of JWSCL (currently trunk) the exception handling will be a little bit different:

function JwsclGetFileOwner2(const FileName: string;
  out Domain, Username: String): TOwnerResult;
var
  F : TJwSecureFileObject;
  Owner : TJwSecurityId;
begin
  F := TJwSecureFileObject.Create(FileName);
  try
    Owner := F.Owner; //Owner is cached/freed by TJwSecureFileObject
    try
      Domain := Owner.GetAccountDomainName();
      Username := Owner.GetAccountName();
      Result := orName;
    except
      on E : EJwsclSidNotMappedException do //not mapped error is handled differently
      begin
        Domain := '';
        Username := Owner.StringSID;
        Result := orSID;
      end;
    end;
  finally
    F.Free;
  end;
end;

If you use JWSCL (Version >= 0.9.2a) and enable the compiler switch JWSCL_SIDCACHE in file Include\Jwscl.inc, JWSCL will add a SID cache (for all TJwSecurityID instances globally). In this way LookupAccountSid will be called only once for every unknown SID and thus SIDs that were already translated are retrieved from cache instead.

I introduced a function similar to FreeAndNil

procedure JwFree(var Obj);

It just frees an object…in the release build of an application. However, in a debug build it additionally sets the value of obj to $C which isn’t a valid memory address. So “Assigned” won’t work here.
Any access to this “freed” member will generate an AccessViolation at address $0000000C. So you will know that a member of JWSCL was used beyond its life time.

procedure JwFree(var Obj);
var
 Temp: TObject;
begin
  Temp := TObject(Obj);
{$IFDEF DEBUG}
  Pointer(Obj) := Pointer($C);
{$ENDIF DEBUG}
  Temp.Free;
end;

I wonder if it should be extended to support different flavors like

1. $C in debug build and don’t touch the value in release (as currently shown)
2. Set the value $C also in release mode.
3. Nil the value in release mode. (quiet death mode)

They could be set by a compiler switch. Still have to think about this though…
What do you think?

Changes

I have commited these changes into the developer branch. They will be published in a next release so the current release won’t break a bad design.

The ACTRL_ACCESS structure is used by the interface method IAccessControl::GetAllAccessRights (and others) which is rather hard to implement yourself because the structure must be created in a single block of memory that can be freed by CoTaskMemFree.

So here is how it looks like

ACTRL_ACCESS design diagram

Luckily, JWSCL will provide an implementation of IAccessControl so don’t worry.

First of all, copying a loaded user profile isn’t possible without the BACKUP privilege. You can’t open already opened files a second time (share deny). The solution is: Either you can use a backup application that runs with the special privilege or you can just use another administrative user (which I did).

There are some keys which have absolute path variables that must be changed, too. But that is a minor problem. The big problem was that Windows could not load the profile of the Administrator. Windows tried to start up the users desktop but then failed with the dialog:  “Windows failed to load user profile.”

It got more confusing because every other user in the system didn’t suffer from this problem. And to top it,  sometimes I could successfully login to the Administrator account.

Solution

In such cases the event manager is a good way to find the error source. In my case, it told me that “NTUSER.DAT” (this is where Windows stores the current user keys called a registry hive) was already opened by another process. I really can’t say why this was the case because it shouldn’t be the case shortly after a fresh boot up. (Of course, the file was correct, it had no write protection, and security was set accordingly)

In such a case you usually have some ways to fix the problem:

1. Reinstall Windows
Good choice. But too much work — and who will promise me that it won’t happen again?

2. Leave Administrator where it was
Also good choice. And I tried it. However my Windows could not handle two profile places somehow and the very same error occured with the old profile location.

3. Live with the situation
Some people do it. I thought about it, too, I have to admit. That’s because there is a user called root in the system now.

4. Find the bug and ignore how much time it will cost.
Ouch. I don’t have time, so not a good option.

5.Create a workaround.
YES! That’s what I did.

So I came up with a practical and fast solution. As I’ve already written, the user’s registry hive could not be loaded.
Why? I don’t know much about it but the registry file was blocked.
Well, I’ve found out that if the Administrator registry hive was already loaded (HKEY_USERS\S-1-5-21-xxx-500 is visible) the Windows could successfully logon the Administrator. I simulated this situation by manually loading the user’s profile using the LoadUserProfile function from Windows API. Well, it always worked!

The next step was to do it automatically before an Administrator could logon. Of course, I could have created a service which loads the user profile at startup but I wanted to be fast so there is another option called Task Scheduler.
Every Windows startup I let run the code above as a simple task with Administrator credentials (needs password).

I don’t know whether the Task Scheduler loads the profile (I would guess so). However the problem is that the profile could be unloaded after the process has ended. So the hive would be removed and logon would no more be possible.

Thus the code above just loads the profile but does not unload it. Since profiles are not watched by Windows (at least in XP) the registry hive  stays loaded and a logon attempt will work (T.Free won’t unload it!).

JEDI Windows Security Code Library used features

• TJwSecurityToken (class)
  
• TJwSecurityToken.LoadUserProfile (method)

However there are some problems:

1. This code does not prevent the user from reverting the process DACL to the original state. An owner of the process can always change the DACL even if she is not listed in it. So the code just prevents a beginner from closing the application forcefully.
2. Any user with the DEBUG privilege can open the process with full access using OpenProcess. The taskmanager uses this way to terminate a process – if TaskManager is started with administrative rights.

The only way to prevent a restricted user from terminating the application is to run the process with a foreign account (e.g. CreateProcessAsUser) and make sure that the user is not listed in the DACL. However if this user gets the DEBUG privilege the game is over.

Why should I use TJwFileStreamEx instead of any other common stream class from the VCL?

Well this question is quite easily answered.

The first thing is that TJwFileStreamEx is based on Memory Mapped Files (MMF). MMF might be the fastest way to access files on your hard disk. Another good reason for using TJwFileStreamEx is its Memory property which is well known from the VCL TMemoryStream class. This property will reduce the effort remarkably.

Getting Started

First you have to include following units to your project:

The signature of our hashing-function looks like this:

The first parameter is used to specify the Algorithm which is used to hash the file data. The second parameter defines the path to the file which hash you want to compute.

So what do we need to calculate the hash of a file? All we need is an instance of TJwFileStreamEx to open the file and an instance of TJwHash to calculate the hash:

This is the basic framework of our function. To calculate the hash of the file we need 2 methods:

HashData tells our instance of TJwHash which data is to be hashed and which size this data has. RetrieveHash calculates the Hash and retrieves a pointer to the hash data.

Finally we have to free the Buffer using the class method

Now our function looks like this:

At last we need to convert the binary hash into a hex-string:

Now we’re done and finally our function looks like this:

How do I use this function?

OK, but what is the advantage of TJwFileStreamEx over other Streams?

Well, you don’t have to load the file into a TMemoryStream and thus the file will not be loaded completely into memory. Furthermore this solution is much faster than a solution using TMemoryStream and similar…

Download

Download the source and binaries of this example (260kiB). This includes the new and necessary JWSCL source files. However you need to download the whole package separately.

1. The process. The auto pointer and thus the object exist as long as the process runs. The object will be destroyed when the process is destroyed.
2. A class or record. The auto pointer exists as long as the class instance exists. If the instance is freed the managed auto pointer object will be freed as well.

What is not a parent object?

1. begin end. In contrast to C++, a begin/end construct does not allow to create a variable scope. You have to create a new function do achieve the same effect.
2. A pointer to an object. Auto pointer to any object (class, record, variable) will not be automatically destroyed. You have to free the memory manually (Dispose, FreeMem) to let the auto pointer take effect.

The current release only allows to create or wrap objects. It is done by the methods of TJwAutoPointer.

The following sample shows how to avoid to manually call free. It uses the Wrap method of TJwAutoPointer to activate the managed pointer mechanism. There is no method to undo this call.

The advantage of the auto pointer approach is that we do not need to call Free for every possible exit. Even exceptions cannot avoid that the managed object is destroyed.
The next sample demonstrates this fact.

The same way can be used to add the IJwAutoPointer variable into classes and records.

A call to X returns:

Create :1
Create :2
Destroy: 1
Destroy: 2

As you can see, the managed object (Name : “2″) is shortly destroyed after the parent object is destroyed. You should know about this fact, because accessing the parent object will fail (if you are luck) in an exception.

A call to Y(false) returns

Create :1

A call to Y(true) returns

Create :1
Destroy: 1

The next release of JWSCL will bring support for pointers created by New and GetMem as well as LocalAlloc. It will also implement thread safe locking mechanisms.

[Update]

There is no need to save the COM object if you want to keep the object only alive in a single function.
Just wrap it.

You even can wrap it several times. All wrapped up instances will be freed, regardeless of the variable’s name.

Of course you can’t access the first object anymore. But sometimes it comes quite handy.

All the source is doing is to get a user’s token by calling CreateWTSQueryUserToken and then duplicate so it will become possible to change the Token SessionID. The session ID is changed by setting the property TokenSessionID which is only possible with the TCB privilege (we need it, but it needn’t to be active).
You can do the CreateProcess part a little better if you read this: “CreateProcess in full glory“.

Did you know?
1. You can test this example in your own Delphi environment without writing a service first.

2. It is not possible to change the session ID of a running process.