macOS Performing actions as Root

[cblackburn]

Hi all,

I have an app where a portion of the code has to be executed as root. On PowerPC I used CoreFoundation to obtain root authorisation and run a unix based helper program. Now that I am making the program Universal I have run into a problem.

The CF code still works but it always executes the PowerPC helper program, even on the Intel architecture. Is there a way I can get it to automatically execute the Intel or PowerPC executable. If not then is there an easy way to obtain the architecture type from the system?

Thanks

Chris

 

[caveman_uk]

int i=1;
char *p=(char*)&i;
BOOL runningOnIntel=(p[0]==1);
if (runningOnIntel)
    NSLog (@"RunningOnIntel");
else
    NSLog (@"RunningOnPowerPC");

BTW, is your helper also compiled as a universal binary?

 

[cblackburn]

BTW, is your helper also compiled as a universal binary?

Hmmm, I didn't know you could compile unix command line programs as universal binaries.

Thanks

Chris

 

[cblackburn]

Also, is it possible to add the helper project as a sub project of the main program?. At the moment I have to compile at as a separate project and add it to the original project as a resource and use it that way.

Thanks

Chris

 

[caveman_uk]

Hmmm, I didn't know you could compile unix command line programs as universal binaries.

Even if you can't in xcode (I don't know for sure) you can from the command line by compiling for both architectures separately then using lipo to give one universal binary.

 

[MrFrankly]

int i=1;
char *p=(char*)&i;
BOOL runningOnIntel=(p[0]==1);
if (runningOnIntel)
    NSLog (@"RunningOnIntel");
else
    NSLog (@"RunningOnPowerPC");

That's a very very dirty (read: ingenious) hack to find out the architecture. I like it!

 

[robbieduncan]

Even if you can't in xcode (I don't know for sure) you can from the command line by compiling for both architectures separately then using lipo to give one universal binary.

You can easily in XCode. I've got a similar piece of code that allows for authenticated copies to /Library/Application Support (instead on ~/Library) and it's simply a case of checking the architectures in XCode.

 

[caveman_uk]

That's a very very dirty (read: ingenious) hack to find out the architecture. I like it!

Thanks

There are probably nicer looking ways using Gestalt functions or whatnot but that bit of code does work. I use it in BeerAlchemy when reading a foreign binary file format.

 

[robbieduncan]

Thanks

There are probably nicer looking ways using Gestalt functions or whatnot but that bit of code does work. I use it in BeerAlchemy when reading a foreign binary file format.

It probably works in the file read context but this can't tell the difference between different architectures that have the same endian style, or am I missing something?

Clearly this is not an issue right now, but it's not very future proof. For example if you wanted to launch an x86-64 bit binary when you were on a 64 bit Intel platform this would not work for you, but the Gestalt alternative should be able to tell the difference.

That all said when you launch a Universal binary it should automatically do the right thing (64-bit versions included). I imagine in Leopard we may well start seeing 3 architectures in some apps: PPC, x86-32 and x86-64...

 

[caveman_uk]

It probably works in the file read context but this can't tell the difference between different architectures that have the same endian style, or am I missing something?

Basically for my purposes I needed to know if I was running on an Intel x86 processor or a PowerPC. The 64 bitness was not a concern. The actual reason was the binary file format stored some values as floats. AFAIK whilst there are various byte swapping routines provided by Apple for ints (such as CFSwapInt32LittleToHost) there isn't one for floats or shorts. Consequently when running on PPC I have to do the byte swapping myself for the others.

Clearly this is not an issue right now, but it's not very future proof. For example if you wanted to launch an x86-64 bit binary when you were on a 64 bit Intel platform this would not work for you, but the Gestalt alternative should be able to tell the difference.

Depends if you're using a 64-bit binary. I'm not. In the event I do then I'd obviously have to revisit the code.

That all said when you launch a Universal binary it should automatically do the right thing (64-bit versions included). I imagine in Leopard we may well start seeing 3 architectures in some apps: PPC, x86-32 and x86-64...

I guess my case was a bit unusual. It's the only time I've actually had to worry about endiannness. Of course if Apple introduces a swap for floats and shorts that would be best of all.

 

[Krevnik]

That all said when you launch a Universal binary it should automatically do the right thing (64-bit versions included). I imagine in Leopard we may well start seeing 3 architectures in some apps: PPC, x86-32 and x86-64...

There are four architectures in the frameworks, ppc64 is one too. Expect that people /should/ be building 4 archs.

I think that the best solution is to compile the helper app as a universal binary. You can do this using lipo as stated above, or by converting your Makefile project into a sub-project in XCode. You can create command-line utility targets in XCode, and you can link it against CoreFoundation, the C++ libs, or just the basic C libs. You get the universal support pretty easily this way without too much hassle, and converting over is just adding your source code to this new target.