Re: Using Authorization Services with a Factored Application
Re: Using Authorization Services with a Factored Application
- Subject: Re: Using Authorization Services with a Factored Application
- From: Simone Manganelli <email@hidden>
- Date: Mon, 15 Dec 2003 16:23:03 -0800
Thanks a lot for your very detailed e-mails on how to correctly create
a factored application. I'm just going off of what other people have
told me (and what I can glean from the documentation). It did occur to
me that leaving the helper application open could be a security risk,
but I didn't know there was a way around the problem.
Anyway, one question I have is about your recommendation to use pure C
instead of Objective-C. Is there a reason for suggesting to do this?
It seems like it'd be easier to use Objective-C, since a lot of the
methods I want to use make it easy to write the files to disk (like
writing plist files by invoking the writeToFile:atomically: method of
NSDictionary).
The other question I have is what the best way is to pass such
information to the helper tool (like an NSDictionary full of key-value
pairs). Should I pass it as an argument when launching the
application, should I use an NSPipe, or should I use distributed
objects like the other poster suggested?
-- Simone Manganelli
On Dec 15, 2003, at 2:41 PM, OL&L Dev 2 wrote:
Hi Simone.
Use a CoreFoundation Tool template for the tool - not an app template.
The tool doesn't need to use the app template. You don't want any of
the app event loop bullshit running in your tool. You just want your
tool to be one solid chunk of executable code that fires off and then
completes. There is no need to keep the tool running.
In fact, it is *dangerous* to keep the tool running. The idea of a
tool is to put security-critical code into it, run it, then exit. You
don't want your tool continuously running as it defeats its purpose -
hackers can hack things that run continuously. They can't hack
something that is not running.
The tool should be as small as possible: enter privileged mode,
execute your root code, exit privileged mode, then quit the tool.
Period.
If your app holds the AuthorizationRef and you are concerned about it
being root, then add your own right, and then request it only just
before you call the helper tool - on the same AuthorizationRef that
your app holds. This way you can authenticate once, keep the AR
around, but not cause a security risk. Keep the ref around in the app,
but get the right *only* before you execute the tool. This prevents
malicious code from executing your tool with a root AR whenever it
wants to. When the tool returns, immediately destroy the right
attached to the AR, and then use the same AR to get the right again
just before you execute the tool the next time. And most importantly:
ONLY enter privileged mode insidethe tool. The app should *never*
enter privileged mode. Not ever.
In summary:
App->Creates the AR (once)
Repeat:
App->Requests the right
App->Calls MoreSecurity to execute the tool
App->Ddestroys the right but not the AR
end repeat
When the app quits,then it frees the AR
This enables you to authorize once but execute the tool many times.
Hence you avoid all those repeated dialogs from popping up.
Easy eh?
The tool should just be a single piece of static code that you load
and fire off each time you call it- hopefully by calling it using
Apple's MoreScurity library.
Just write the tool in C, get your data into it, call it, then return.
Simple. Modular.
Best Regards,
Orbital Launch, & Lift, Inc.
http://www.orbitallaunch.com
Hmm... one question I still have, which also might explain my
confusion: are you using a regular "Cocoa Application" target, or are
you using a "Shell Tool" target (that's what it's called in Xcode
anyway). Because I'm unable to use regular Objective-C style methods
with the Shell Tool, because it wants the @interface/@end and
@implementation/@end blocks around them before the compiler will stop
throwing errors. And then it wants a principal class and an
Info.plist file, which ends up making it a regular "Cocoa Application"
target.
Or is it OK to use a "Cocoa Application" target for a faceless
background tool?
-- Simone Manganelli
On Dec 14, 2003, at 9:27 PM, Jonathan Wight wrote:
Hi,
I have something like this in my helper's main object:
- (void)startServing
{
+create a distributed object here;
// runLoop is a member variable
while (runLoop != NULL)
{
// give the runLoop 1 second...
[runLoop runUntilDate:[NSDate dateWithIntervalSinceNow:1.0f];
}
}
- (void)stopServing
{
[connection invalidate];
[connection autorelease];
connection = NULL;
[runLoop autorelease];
runLoop = NULL;
}
Then from the main app you get a get a proxy (actually an
NSDistantObject) to the helper object, call whatever methods you need
to do your specific work and when finished call stopServing. That will
invalidate the connection and terminate the run loop (at most waiting
1 second for the runloop to finish).
Hope this helps.
Jon.
On Dec 14, 2003, at 23:09, Simone Manganelli wrote:
Jon --
I did not know about distributed objects. Thanks for the tip! It
looks like it has the potential to solve many of the problems that I
came across. One question, though: how does Distributed Objects allow
you to tell the helper when to quit? Do you just put the helper to
run in a loop, or what?
-- Simone Manganelli
On Dec 14, 2003, at 8:02 PM, Jonathan Wight wrote:
I only use pipes to bootstrap the communication between main app and
the helper - by this I mean the helper's PID, the flattened
AuthenticationRef (if needed) and some problem specific info. After
that I'm using Distributed Objects for all communication. It makes
executing code in the helper really easy and the helper quits when I
tell it to quit.
Jon.
On Dec 14, 2003, at 16:45, Simone Manganelli wrote:
I was wondering how to get around this limitation, or if there's a
better way to do what I want to avoid the problems I've been having.
The other minor question I had is how I prevent the helper tool from
quitting, so that the user doesn't have to authenticate to relaunch
the helper tool and perform more admin-priv operations (which is why I
even started trying to code the helper tool, anyway).
If anyone can provide any guidance with these issues, I'd be very
grateful.
-- Simone Manganelli
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.