Using Windows ACL-functions

[ChrisTG]

Hi there,

I'm trying to use function GetNamedSecurityInfo() to read the ACL of a folder structure.
The code looks like this:

Code: [Select]

dwError := GetNamedSecurityInfo(pAnsiChar(Filename), SE_FILE_OBJECT, DACL_SECURITY_INFORMATION, nil, nil, @ExistingDacl, nil, @psd);
Unfortunately the compiler complains:

Code: [Select]

D:\workspace\Libs\MyFileUtils.pas(54,70) Error: Incompatible type for arg no. 2: Got "SE_OBJECT_TYPE", expected "_SE_OBJECT_TYPE"
If I try to change to _SE_FILE_OBJECT, I get the following error message:

Code: [Select]

D:\workspace\Libs\MyFileUtils.pas(54,71) Error: Identifier not found "_SE_FILE_OBJECT"

Strange is, that the function is defined in JwaAclApi as:

Code: [Select]

function GetNamedSecurityInfo(pObjectName: LPTSTR; ObjectType: SE_OBJECT_TYPE;
  SecurityInfo: SECURITY_INFORMATION; ppsidOwner, ppsidGroup: PPSID; ppDacl,
  ppSacl: PPACL; var ppSecurityDescriptor: PSECURITY_DESCRIPTOR): DWORD; stdcall;
So, from my point of view SE_FILE_OBJECT should be fine??

Has anyone a solution for this problem?

TIA,
Chris

[marcov]

Probably you have some identifier conflict, or multiple getnamedsecurityinfo declarations. Maybe Jedi and FPC Windows unit both define it.

 IOW two different units export the same identifier, and the compiler wants the type one that belongs to the getnamedsecurityinfo call, but you pass a type declared in some other unit.

Try to make a minimal program with only the GetNamedSecurityInfo call (it must only be compilable, not runnable). If that succeeds, then start adding your own units till it goes wrong.

Usually such conflicts are worked around by prefixing the identifiers (getnamesecurityinfo and SE_FILE_OBJECT or its type) with the unit name (e.g. jwaaclapi.getnamedsecurityinfo etc)

[ChrisTG]

Hi marcov,

thanks for your reply!

Ok, I've created a "bare minimun" version of the problem.
But I still don't see any double definitions that could cause the error.
I've attached the project files to this post, could you please drop a quick look on them?

Thanks,
Chris

[Cyrax]

Hi there,

I'm trying to use function GetNamedSecurityInfo() to read the ACL of a folder structure.
The code looks like this:

Code: [Select]

dwError := GetNamedSecurityInfo(pAnsiChar(Filename), SE_FILE_OBJECT, DACL_SECURITY_INFORMATION, nil, nil, @ExistingDacl, nil, @psd);
...

You need to declare new variable which have type of SE_FILE_OBJECT and feed it to GetNamedSecurityInfo function.

Like this:

Code: [Select]

  Var
    AFileObject : SE_FILE_OBJECT;
...
dwError := GetNamedSecurityInfo(pAnsiChar(Filename), AFileObject, DACL_SECURITY_INFORMATION, nil, nil, @ExistingDacl, nil, @psd);

And I think you need to same for DACL_SECURITY_INFORMATION.

[Cyrax]

Hi marcov,

thanks for your reply!

Ok, I've created a "bare minimun" version of the problem.
But I still don't see any double definitions that could cause the error.
I've attached the project files to this post, could you please drop a quick look on them?

Thanks,
Chris

Remove Windows, JwaAclApi and JwaAccCtrl units from uses clause. Then add only JwaWindows in there.

[ChrisTG]

Hi Cyrax,

thanks for your reply.

Removing all but JwaWindows solves the problem with the stripped down example project, but I can't use that as a solution in my normal project since I need units like "Windows" there.
Defining variables and passing them to the function call instead of the types does not change anything. The compiler still complains about an incompatible type.
Where is that "correct" SE_FILE_OBJECT defined? Can I use something like <UnitWithCorrectDefinition>.SE_FILE_OBJECT in my code? Would that work?

[ChrisTG]

I think I figured it out. I simply have to write "JwaWindows." in front of ALL references in that function call. This way the complier gets the right definitions and the code can be compiled without errors.
Strange, that this is not needed in Delphi.

However, my problem is solved - so thanks again for your support!

cheers,
Chris

[marcov]

Maybe Free Pascal has some of these declarations in unit Windows.  The delphi behaviour might be version specific

[Leledumbo]

JWA prefix means the unit comes from JEDI Windows API project, which is initially made to be Delphi compatible. FPC also wraps Windows API, but the content might not be compatible with JWA / Delphi one.

[marcov]

JWAwindows is afaik also not compatible with Delphi windows.  Put the jedi units last in the uses clause.