Welcome to the MacNN Forums.

Gametes · Mar 2, 2002, 09:33 AM

So this has been done a thousand times already, and I'm looking to duplicate it on another tool I use all the time. I have a unix app I run in the terminal, and I'd like to make a cocoa front-end for it, from which I can open/edit/save files, send input/get output from the workhorse of the unix program, and adjust settings.
It sounds like a real app, I know, but I think I'm actually asking for very little. If you think about it, this app doesn't really do anything; all the real work is done in the app somebody else has written. My app is just a nice interface.
So anyway, does anybody know of a tutorial that specifically addresses this, or can walk me through the basics themself? thanks...

seb2 · Mar 2, 2002, 10:34 AM

personally, i can recommend two articles on cocoadevcentral:
http://www.cocoadevcentral.com/tutor...w=00000017.php
and http://www.cocoadevcentral.com/tutor...w=00000024.php

and i think i've seen something on stepwise.com; basically, any halfway decent documentation on nstask will do, it's quite straightforward.

Apocalypse · Mar 2, 2002, 03:01 PM

Yeah, seb2 is right. Those tutorials from CocoaDevCentral were very useful. If all you need to do is run and communicate with those apps the NSTask will be all you need. If you need to launch anything as root, however, it gets a little more difficult. I can post some code for using the security framework if you need that, too.

Good luck,
Jeff.

ksuther · Mar 2, 2002, 04:49 PM

Apocalypse PLEASE post some example code, I've never gotten the Security framework stuff to work

matthewmodern · Mar 3, 2002, 08:26 PM

I also very much would like to see a good example of authorizing a wrapped program to run with root privs; Apocalypse, please post this.

-m

Apocalypse · Mar 4, 2002, 12:37 AM

Well, here is part of my security abstraction layer. It probably could be cleaner but I don't have the time to fix it up.

<BLOCKQUOTE>code:<HR><pre>

AuthorizationRef authRef;

- (void)createEnv
{
AuthorizationRights tempRight;
AuthorizationFlags tempFlag;
OSStatus temperr = 0;
tempRight.count=0;
tempRight.items = NULL;
authRef=NULL;
tempFlag = kAuthorizationFlagDefaults;
temperr = AuthorizationCreate(&tempRight, kAuthorizationEmptyEnvironment, tempFlag, &authRef);
}

- (BOOL)authorizeThis

char *)pathy
{
OSStatus authErr = 0;
AuthorizationRights righty;
AuthorizationFlags flagy;
AuthorizationItem thingy[1];

thingy[0].name=kAuthorizationRightExecute;
thingy[0].value=pathy;
thingy[0].valueLength=strlen(pathy);
thingy[0].flags=0;
righty.count=1;
righty.items = thingy;
flagy = kAuthorizationFlagInteractionAllowed | kAuthorizationFlagExtendRights;
authErr = AuthorizationCopyRights(authRef,&righty, kAuthorizationEmptyEnvironment, flagy, NULL);
return (errAuthorizationSuccess==authErr); //this should remove a branch and make the code more efficient
}

- (void)loseSecurity
{
AuthorizationFree(authRef, kAuthorizationFlagDestroyRights);
}

-(int)launchSecure

NSString *)path withArgs

NSArray *)args
//this is used to create a new secure task with the associated path and argument array.
//return: an integer that represents the task number
{
OSStatus err =0;
FILE* pipey;
char *pathy;
char *argt[4];
int counter;
char *temparg = malloc(sizeof(temparg));

//first make sure that we are looking at a valied binary (ie: not with trailing '/')
if([[path substringFromIndex

[path length]-1)] isEqualToString:@"/"]){
//we are looking at a directory (most likely another method decided that there are no valid binaries in this bundle)
return -2; //this code is different than the usual erro (-1) since it is slightly different
}
for(counter=0;counter<[args count];counter++){
[[args objectAtIndex:counter] getCString:temparg];
argt[counter]=temparg;
// NSLog(@"Logging number %d: %s", counter, temparg);
temparg = malloc(sizeof(temparg));
}
argt[counter]=NULL;
// [path getCString:temparg];//periodic error here
pathy = [path cString];//temparg; //this line is supposed to create a qualifier warning (???)
output=[NSFileHandle alloc]; //why is this here when it is never used?
[self createEnv];//create the environment
if (![self authorizeThis

athy]){
return -1;//error code
}

err = AuthorizationExecuteWithPrivileges(authRef, pathy, 0, argt, &pipey);
if(err){
return -1;
}

//I am going to try this without losing the security
//[self loseSecurity];

//right before we get out of here lets free up the memory
free(temparg);
for(counter=0;counter<[args count];counter++){
free(argt[counter]);
}
return 0;//replace this with something better later
}

[/code]

Given that code, you should be able to just call [self launchSecure

athToTool withArgs:argumentArray]

This is a snippet from "Skeleton Key" which is a rather popular program my company makes. We are planning to release the entire source code soon.

Hope you guys find that useful,
Jeff.

matthewmodern · Mar 4, 2002, 10:19 AM

Apoc, very useful (much cleaner than other implementations I have seen); but it still doesn't solve the two biggest problems I am having. Any idea about these two suckers?:

1. Passing environment variables. Normally you can do this in NSTask setEnvironment:NSDictionary*)dictWithEnvVars. I don't see a similar way to implement this through AuthorizationExecuteWithPrivileges(). If you are calling binaries which resides in your bundle, you sometimes NEED environment variables for it to find support files properly.

2. Is there a simple way to get the FILE* type file-handler to convert into a NSFileHander? Using "mr. buffer overflow" ('fread') for a C file handler seems really inflexible compared to using NSFileHandler availableData:, and I can't for the life of me figure out a good (and safe!) way to do the equivalent of a "while ([NSData data = [NSFileHandler availableData:] length])" loop to pipe the output of the subprocess and provide instant feedback to the user for a process which make take a long time and have a lot of output.
(Also, by default does the FILE* handler take both stdout and stderr?)

3. Why oh why oh why didn't Apple just allow us to have authorized NSTasks? That would make everything about a jillion times simpler.

Angus_D · Mar 4, 2002, 01:04 PM

Originally posted by matthewmodern:
1. Passing environment variables. Normally you can do this in NSTask setEnvironment:NSDictionary*)dictWithEnvVars. I don't see a similar way to implement this through AuthorizationExecuteWithPrivileges(). If you are calling binaries which resides in your bundle, you sometimes NEED environment variables for it to find support files properly.

AEWP() is designed for installers, there are several shortcomings with it. Instead use a self-repairing app with a setuid root tool. See AuthSample (http://developer.apple.com/samplecode) and the Authorization Services draft reference (developer.apple.com/techpubs -> OS X -> Core Services, I think).

Also, why do you need env vars? Won't arguments do?

3. Why oh why oh why didn't Apple just allow us to have authorized NSTasks? That would make everything about a jillion times simpler.

Exactly the reason you gave. You don't want everybody and their mother doing authorized tasks on your computer!

Seriously though, if you have a self-repairing setuid tool you can probably use NSTask to launch it.

matthewmodern · Mar 4, 2002, 01:46 PM

Originally posted by Angus_D:
Also, why do you need env vars? Won't arguments do?

Well, unless you a wrapping a BSD tool which doesn't provide arguments for the option (as is my current case).

I will look into the setuid root method.. the Apple AuthTool example seemed a bit over my head (and poorly documented), and also seemed to imply that you put the authorization and self-repair code inside the wrapped tool itself.. not an option if you are wrapping a precompiled tool. I'm sure there is a way to have a program that setuids a separate binary, but I don't know how to go about doing this (especially since while I know the Cocoa framework, I am not a traditional C/Unix programmer).

Exactly the reason you gave. You don't want everybody and their mother doing authorized tasks on your computer!

Well, authorized tasks by their nature require the users to authenticate for access. So its not like by making this more difficult for programmers Apple is enforcing better security. Rather, quite the opposite, since it seems likely that programmers will then make mistakes that could cause potential security leaks. I'm sure we can all agree that arbitrarily granting setuid root to a binary executable included in the application bundle is NOT good security practice in the long run (especially without any sort of digital 'signature' checking).

matthewmodern · Mar 4, 2002, 01:56 PM

Examining the comments in the authTool sample code another huge problem with bundled setuid apps appears.

/* The tool could disappear from inside the application's package if a user tries to copy the application. Currently, the Finder will complain that it doesn't have permission to copy the tool and if the user decides to go ahead with the copy, the application gets copied without the tool inside. At this point, you should recommend that the user re-install the application. */

If you use that method, the user can't copy/move the application. That's not exactly the Macintosh way.