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: Oleg Svirgstin <email@hidden>
- Date: Mon, 15 Dec 2003 06:01:40 +0300
Hi,
I am not quite sure I understand the problem.
"@interface..@end" block does not make a standard application. "self" is a
feature of Objective-C, defined in its runtime (the first argument to
obj_msgSend()).
If you create a privileged helper as a Foundation Tool, you won't seem to
violate too many of the rules. A Foundation Tool is not "a complete
application" but a good old command line tool. You will be in position to
use methods of NSFileHandle and of any other Foundation classes in it. I
don't see any objection in making it loop until it gets proper data or
flushes something back to the caller. However, it is not secure to leave it
running for too long. Security means that the user will have to confirm her
authentication again and again. Otherwise a bad guy will break into the OS.
If your helper tool is in plain C, you may use "unix" pipes. Or
CoreFoundations (you will have to add the CF framework to the helper's
project).
It is a complete "NSApplication" application that should NOT be used as an
authorized setuid helper.
See AuthSample and MoreAuthSample (at the Apple site).
Hope this helps...
Regards
Oleg
>
From: Simone Manganelli <email@hidden>
>
Date: Sun, 14 Dec 2003 14:45:27 -0800
>
To: Cocoa-Dev List <email@hidden>
>
Subject: Using Authorization Services with a Factored Application
>
>
I'm trying to implement authorization in my application, using
>
Authorization Services by factoring my application into the GUI
>
portion, and a helper tool to execute the authorized actions.
>
>
I understand that by using a factored application, I can allow a user
>
to be authorized to do certain actions indefinitely, instead of using
>
AuthorizationExecuteWithPrivileges, which is an expiring right. The
>
other thing that I've noticed is that in the Authorization Services
>
documentation, it states that the setuid bit and owner are preserved
>
when copying applications in Jaguar and later, so since my application
>
is only going to run on Jaguar and later, I don't have to worry about
>
doing self repair. Is this correct?
>
>
Anwyay, here's my main question: I've figured out how to communicate
>
between processes using NSTask and NSPipe (which seems to work OK), but
>
the only problem is that when using an NSPipe (combined with an
>
NSFileHandle), I want to set up a way to notify the helper tool of when
>
new data has been passed to it, so that I don't accidentally get two
>
sets of data all at once from the file handle (using the availableData
>
method). NSFileHandle seems to have another method that will help me
>
do this (waitForDataInBackgroundAndNotify), but this requires that I
>
add the helper tool as an observer for notifications. When I try to do
>
this, I get an error with using "self" in the code, because I'm not
>
subclassing an NSObject which makes that variable undefined.
>
>
The other thing is that the helper tool file doesn't like Objective-C
>
style methods (e.g.: - (void)dataAvailable:(NSNotification
>
*)theNotification; ) when they're not inside a @implementation/@end
>
construct, and that requires a @interface/@end construct as well,
>
effectively making my helper tool another standard program instead of a
>
helper tool.
>
>
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.