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.

[Update]
The fix is currently only available in the developer version repository (aka trunk) of Subversion.

Internally the Connect method of TJwTerminalServer verifies the connection to Terminal Server by reading some property. This is done because of a change in the API’s by Microsoft: opening a handle with WTSOpenServer to a nonexisting server actually returns a valid handle. I reported this as a bug to Microsoft some time ago and the “fixed it” by changing the documentation.

For those interested in the code: it is a class function called IsValidServerHandle which can be used to verify a handle returned by WTSOpenServer:

class function TJwTerminalServer.IsValidServerHandle(const hServer: THandle): Boolean;
var
  dwSize: DWORD;
  WinStaInfo: WINSTATIONINFORMATIONW;
begin
  { All Windows < Vista return 0 on Invalid handle }
  Result := hServer <> 0;

  { No need to continue if it's already invalid... }
  if not Result then
    Exit;

  { For Windows >= Vista we need to make a query to be sure
    A non valid connection will fail on WTSQuerySessionInformation and will
    return LastError RPC_S_SERVER_UNAVAILABLE }
  if (TJwWindowsVersion.IsWindowsVista(True)) or
    (TJwWindowsVersion.IsWindows2008(True)) then
  begin
    Result := WinStationQueryInformationW(hServer, 65536, WinStationInformation,
      @WinStaInfo, sizeof(WinStaInfo), dwSize) or (GetLastError() <> RPC_S_SERVER_UNAVAILABLE);
  end;
end;

A more visible change is the introduction of the Session function of TJwTerminalServer, with this function you can get all details for a specific session. It is meant for those cases where you need only one specific session and is of course far more efficient than enumerating all sessions, retrieving all sessions details and then finding the particular session in the SessionList.

The signature of the function is:

function TJwTerminalServer.Session(const SessionId: TJwSessionId = WTS_CURRENT_SESSION): TJwWTSSession;

Note that the parameter is default so you can call both:

Session := TS.Session;  // Retrieve the current Session

and

Session := TS.Session(1); // Retrieve the session with SessionId 1

It is important to understand the difference between Session and Sessions: where Session returns an instance of TJwWTSSession, SessionS returns a SessionList. This is especially important because Session works with a SessionId parameters and Sessions (being a TObjectList descendant) is accessed with by Index which is just the position in the ObjectList.

If a Session is not found an EJwsclWinCallFailedException will be raised so you’d better wrap the call into a try..except handler!

The last remark is that you, the caller, are responsible for freeing the object so a more complete sample would be like this:

var
  TS: TJwTerminalServer;
  Session: TJwWTSSession;
begin
  TS := TJwTerminalServer.Create;
  try
    try
      Session := TS.Session;
      try
        // Work with the session object
        ShowMessageFmt('Username=%s', [Session.Username]);
        Session.PostMessage('Hello from the Jedi guys!', 'Message', MB_OK);
      finally
        FreeAndNil(Session);
      end;
    except
      // Handle Exception here!
    end;
  finally
    FreeAndNil(TS);
  end;
end;

You can still use 0.9.2a because bugs and problems will still be fixed (until told otherwise). However, there won’t be added any new features. To get new features you need to upgrade to a newer version.

Details

The problem is located in class TJwWindowsVersion (unit JwsclVersion.pas) where all IsWindowsXXX routines  return false if you check for a specific Windows Version or newer (Parameter set to true) and run it on Windows 7.

How to Update

There is no separate download, but you can update your local source if you have “.svn” folders in your JWSCL folders. Just use a Subversion client like TortoiseSVN and open the Explorer’s context menu to selected “SVN Update” on the root folder of JWSCL (e.g. JWSCL\0.9.2a\).

Update <-> Upgrade

Be aware that update means that you get the latest changes for this version (e.g. 0.9.2a). So you won’t upgrade to any newer version like 0.9.3.

Update Notifications

You can subscribe to a mailinglist to get notified about changes in JWSCL and JWA. Just subscribe to jedi-apilib-wscl-svn (also use this link to subscribe). Furthermore there is an archive to see all commits of JWSCL and JWA.

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)

After long back and forth trying to find the error by reviewing codes, I decided to go back to an older version of JWSCL. I had to get back about 300 revisions (commits) to find a working JWSCL code. However I still couldn’t find out what the difference was until…

Well, after the 301th revision (anywhere near that) I decided to rewrite the codes which maintain the access control list and elements for WinAPI functions (structures like ACL, ACE_HEADER) . I conducted intensive tests but it seemed that this particular function GetInheritanceSourceW wasn’t tested at all! Shame on me.

… until I could compare old, but working ACL structures with new ones. Each ACL consists of access control elements (ACE) which usually look like this:

(XXX stands for ALLOW or DENY.)

This record is much more complicated than it looks. If you need to find out its real size you cannot just use the sizeof operator. Some background information will explain why. An ACE consists of a header which is also a structure (but not the problem here), its access mask (no problem again) and a SidStart. What about the Start in Sid? Well, a Security Identifier (SID – the user’s ID) is assigned to every ACE. But how does it work? A SID is a variable length structure. And so usually, we store a SID into a structure and retrieve a pointer to it. But a DWORD is apparently not a pointer and it would not be a good idea to just typecast it to DWORD. The main idea is that SidStart is a placeholder where the SID structure starts. If you’re ever going to create an ACE structure you need to create a block of memory that can hold the first two members of the ACE structure and the SID you want to store. So actually the ACE structure looks like this:

As you already figured out, this structure is invalid in Delphi. However it should just show you how the structure is intended to be used.

The bug, this article is about, came from the fact that in addition to the size of the structure, the size of the SID was added. So in total 4+4+4+x = 12+x bytes were returned where x is size of the SID.
The real size is in fact: 4+4+x = 8+x bytes.

The reason why this can be a problem comes from the fact that these ACE structures are stored in a row in memory. If you jump 12+x bytes from the first ACE structure you’ll get to the second one. 12+x bytes more you have the 3rd one and so on. The size of an ACE structure is applied to the AddAce function so it knows how far to jump to get to a specific ACE. However if a function doesn’t care about the size and uses the “correct” 8+x bytes to jump – well, it gets messy.
IMO this happened here.

Many functions obviously don’t care about this because they use the official API (GetAce etc) . I didn’t find this problem because I’ve used a lot of JWSCL functions which internally convert the ACL classes to C-structures with no problem most of the WinAPI functions. However GetInheritanceSourceW is a big function which is messing around with the ACL directly to obtain the correct inheritance path. I didn’t try to understand it completely because I’ve already created a method which simulates the behavior of the original. I call it TJwSecureFileObject.GetFileInheritanceSource (currently only files are supported).

Strange things can happen if you dive deep into Win32 programming. As an advice you should always check every byte several times over and over to avoid or find such errors.

Happy programming!

Update

This error was fixed in revision 761 of 0.9.2.a branch and, of course, the developer version (trunk).