I’d like to know if it’s possible to keep acquired auth over time.
Here’s my code:
- (IBAction)toggleAuthentification:(id)sender {
if (AuthorizationCopyRights(authRef, &authRights, kAuthorizationEmptyEnvironment, authFlags ^ kAuthorizationFlagInteractionAllowed, NULL) == errAuthorizationSuccess) {
AuthorizationFree(authRef, kAuthorizationFlagDestroyRights);
authRef = NULL;
AuthorizationCreate(NULL, kAuthorizationEmptyEnvironment, kAuthorizationFlagDefaults, &authRef);
[sender setState:NSOffState];
} else if (AuthorizationCopyRights(authRef, &authRights, kAuthorizationEmptyEnvironment, authFlags, NULL) == errAuthorizationSuccess) {
AuthorizationMakeExternalForm(authRef, &extAuthRef);
[sender setState:NSOnState];
NSDictionary *authRightInfo;
if (AuthorizationRightGet(authRights.items[0].name, (CFDictionaryRef *)&authRightInfo) == errAuthorizationSuccess) {
//[authRightInfo valueForKey:@"timeout"] == 300
keepAuthTimer = [NSTimer scheduledTimerWithTimeInterval:([[authRightInfo valueForKey:@"timeout"] unsignedShortValue] - 10) target:self selector:@selector(keepAuthentification:) userInfo:nil repeats:YES];
}
} else {
[sender setState:NSOffState];
}
}
- (void)keepAuthentification:(NSTimer *)aTimer {
NSLog(@"%d", AuthorizationCopyRights(authRef, &authRights, kAuthorizationEmptyEnvironment, authFlags ^ kAuthorizationFlagInteractionAllowed, NULL));
NSLog(@"keepAuth", aTimer);
}
Step 1 : click on button that call toggleAuthentification: and auth successfully.
Step 2 : After 290 seconds I receive 0 and keepAuth from console, so, my NSTimer works.
Step 3 : wait few more second (more than 10) and click again on my button. Auth panel reappear !!!
Why my call to AuthorizationCopyRights into keepAuthentification: do not reset the 300 seconds (for this auth right) timeout?
What I’d like to have is app where you have to logging only once per app execution or until you manually request logout by clicking a button.
Where is documented, that
AuthorizationCopyRightsis supposed to reset the timer?AuthorizationCopyRightswill request the requested rights from the security subsystem and the security subsystem will either give the rights straight away or prompt the user for authorization. The timeout after how many seconds the system must request authorization again of the user is configured in/etc/authorizationand it can as well be set to 0, meaning the system always has to re-prompt the user.If you want to use the authorization rights to run a tool with root privileges (a helper-tool) several times in the future, just do the following:
When you need to run the app with root privileges for the first time, ask the user for authorization.
When the authorization succeeds, don’t start the helper-tool directly, but start a helper-helper-tool with root privileges.
The helper-helper-tool keeps running in the background until your application tells it to quit, what it will be the case when your application itself is going to quit or when user de-authorizes.
The helper-helper-tool communicates with your application through some kind of IPC method. E.g.:
It reads commands from stdin – when starting a task, you can get access to its stdin pipe (see parameter
communicationsPipeof AuthorizationExecuteWithPrivileges.If the helper-helper-tool is written in Obj-C, you can use Distributed Objects.
If it is not written in Obj-C and you don’t want to use a file pipe for whatever reason, you may prefer to use UNIX sockets. UNIX sockets work like network sockets, but without using a network protocol or network addresses. Either process opens a server UNIX socket and the other process creates a client UNIX socket and connects it to the server socket. Now both processes can exchange data over that socket (in both directions, since sockets are always bi-directional).
If you must send a lot of data to your helper-helper-tool, all methods above might be rather slow, since they involve data being copied or even being converted, copied and converted again. In that case use POSIX shared memory to transfer the data (it is the fastest way to transfer data between processes, since the data is not transferred at all, it is just available to multiple processes at the same time) and only use any of the methods above to inform the other process that the memory content has been updated.
Now send the helper-helper-tool a command that makes it start the helper-tool (with appropriate parameters). Since the helper-helper-tool runs as root, the helper-tool will also run as root.
As the helper-helper-tool stays alive until you tell it to quit, it can always start another root instance of the helper-tool, when needed.
For the cases you want to run the helper-tool without root privileges, just call it directly without using the helper-helper-tool.
Of course the method above is way too complicated, but probably easiest to adopt to your current code. I would personally not use a helper-helper-tool at all, but instead make the helper-tool itself run permanently in the background. The helper-tool will then either directly perform the requested actions or, if that is not possible for whatever reason, fork itself and then perform the actions (this will not work if you use CoreFoundation, Foundation or certain other Apple frameworks) or fork itself and then re-execute itself with a parameter that tells it to just perform a certain action and then quit. The advantage is that there will be only one helper-tool.