macOS: fileno function

[CCRDude]

I have implemented AuthorizationExecuteWithPrivileges to get some kind of elevation for helper processes. My problem is I need to use the status output.

There's an example processing it this way:

Code: [Select]

// Print to standard output
    char readBuffer[128];
    if (status == errAuthorizationSuccess) {
        for (;;) {
            int bytesRead = read(fileno(pipe), readBuffer, sizeof(readBuffer));
            if (bytesRead < 1) break;
            write(fileno(stdout), readBuffer, bytesRead);
        }
    } else {
        NSLog(@"Authorization Result Code: %d", status);
    }

Now I'm trying this in Pascal and don't know how to use the returned file object, since it seems I need to convert it into a handle (fileno?) first - right now, I always get an error ("Bad file number") on FileRead.

Code: [Select]

if (errAuthorizationSuccess = status) then begin
      repeat
         // we need to use fileno(pipe) here!
         // GetFileHandle does not work
         iBytesRead := FileRead(GetFileHandle(FILE(pipe)), readBuffer, SizeOf(readBuffer));
         if (-1 = iBytesRead) then begin
            WriteLn(SysErrorMessage(fpgeterrno));
         end;
      until (0 >= iBytesRead);
//      FileClose(pipe);
   end;
Any suggestions?

[Jonas Maebe]

Pascal is case-insensitive, so the type FILE is the same as the type File, which is a built-in Pascal type. It is completely different from and unrelated to the C FILE type. I don't think FPC ships with any unit that exports the C FILE type.

It is possible to work around it, but non-trivial (just declaring a Pascal byte array with the same size as the C FILE type may work, but it also may not because of alignment issues, and the size may be different on different architectures). Additionally, the AuthorizationExecuteWithPrivileges function has been deprecated since macOS 10.8, so it's not a good idea to use it.

[CCRDude]

I‘ve seen it has been deprecated for many versions, but it still works and is an easy way. My current Mac won‘t run the latest macOS anyway. So for my current purpose, it does it‘s job well.

For a published tool, I‘ll learn more about launchd daemons.

Thanks for the C FILE structure hint, I‘ll try to find some description of that.

Background: I use multiple Wireguard connections. The Wireguard UI does allow only one at a time, the command line wg tools allow them at the same time. So I‘ve written my own mini UI parsing config files, calling wg show and wg-quick up (name).

I could run my executable using sudo or security, then I could use the simple execution of external tools, but prefer to keep ithe UI non-root, even if the tool is just for me.

[CCRDude]

No full success yet, but something that doesn't trigger errors any more... fpcsrc/rtl/bsd/ostypes.inc does define a type "dirent" (directory entry), which might be what I was looking for.