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: Sun, 14 Dec 2003 21:05:30 -0800
Oleg --
The thing is that if I don't declare an @interface/@end and an
@implementation/@end block, I can't specify what the super class of my
tool is, and so therefore "self" is undefined. The compiler always
throws an error unless I declare my tool to be a subclass of NSObject,
at the very least. That's the only way I've found around the problem,
anyway.
As for the tool, from reading the Authorization Services, I understand
that being able to modify files on the disk is a non-expiring right, so
if I design my application as a factored application, where the helper
tool contains all the code that does the writing to the disk, I can
leave the helper tool open as long as possible as long as I make sure I
always check the authorization reference (so that if the user is
deauthorized, the helper tool will ask for authorization again). This
is what I've been told from an Apple employee when they contacted me
regarding a similar question in the past. So in effect, the user WILL
be authorizing again every time he needs to perform a privileged
action, but entering the password is not required for this process, in
most cases. But the Authorization Services API will effectively
determine when a password is again needed.
As for the problem for which you suggested to have the tool run in a
loop, I suppose that would work. But when I pass information to the
helper tool through a pipe, I want to make sure that I don't get
multiple information in one call (for example, I don't want to retrieve
the data for two authorization references at once for two different
actions that the user invoked that require privileged acess). So I
thought the best way to do that would be through the NSPipe method, but
if I can't specify "self" as an observer (since it's undefined), and
since I can't use standard Objective-C calls (because the compiler
complains that it's not "in a class context", which requires an
@interface/@end and an @implementation/@end block), the delegate won't
work.
Am I making any sense? I really don't have any experience in this
area, but this is what I understand from what I've figured out.
-- Simone Manganelli
On Dec 14, 2003, at 7:01 PM, Oleg Svirgstin wrote:
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.