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: Jonathan Wight <email@hidden>
- Date: Mon, 15 Dec 2003 00:03:20 -0600
I used the "Foundation Shell Tool" target. I then created an NSObject
subclass that provides the methods I needed and in my main function I
created an instance of that class and called its "run" (of course that
name is arbitrary and even optional - I could have put all the behavior
in the init method) method (safely wrapped up in an NSAutoreleasePool).
Although it _is_ ok to use the Cocoa Application target for a
background daemon I think its only needed if you need to pop up a GUI.
But in this specific case (a privileged/suid helper tool) running as a
NSApplication is huge security risk. For lightweight tools link to
Foundation.framework and just define a class and then create that class
in main() and execute it.
Jon.
On Dec 14, 2003, at 23:54, Simone Manganelli wrote:
>
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.
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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.