FROM : Steven Palm
DATE : Wed Dec 15 21:30:53 2004
On Dec 15, 2004, at 3:03 PM, <email_removed> wrote:
>> On Dec 15, 2004, at 2:16 PM, <email_removed> wrote:
>>> Darn. I was hoping that would not be the case.
>>> Question then, can I set /Applications/SomeApp.app as the toolpath?
>>> or
>>> can
>>> I only launch command line tools?
>>
>> Part of the issue here is that when you would make your application
>> run as root, you would also be then granting root level access to all
>> libraries and frameworks you are using, which is relatively speaking a
>> HUGE security hole over putting specific bits of functionality in a
>> standalone and limited helper tool.
>>
>> Take the functions that must be performed as root and wrap them in a
>> helper tool, and have your application call this tool, passing the
>> authorization reference along with the command to perform. You'll be
>> happy you did, really, even though it's extra work.
>
> Explained this way it makes a little more sense. I guess Im just
> concerned that I'll have to re authorize the commandline tool for each
> file that needs removal which would be tedious. Anyway. Back to the
> books
> I suppose.
What you can do is use the sample as shown in AuthSample and MoreAuth
which show the process of having a command line tool repair itself...
That way, they have to authorize the first time so the tool can repair
itself, but then (if you like) subsequent attempts do not need new
authorization. I'd suggest also possibly setting up a custom right or
rights for the operations you want to perform, and then you can change
the timeout value to be whatever you want (including unlimited) so that
once they authorize once upon application startup, they don't need to
do it again until they quit the program. There are lots of options, I
think it's quite flexible. Check out the AuthSample and MoreAuth
examples over at Apple's site.
Steve
DATE : Wed Dec 15 21:30:53 2004
On Dec 15, 2004, at 3:03 PM, <email_removed> wrote:
>> On Dec 15, 2004, at 2:16 PM, <email_removed> wrote:
>>> Darn. I was hoping that would not be the case.
>>> Question then, can I set /Applications/SomeApp.app as the toolpath?
>>> or
>>> can
>>> I only launch command line tools?
>>
>> Part of the issue here is that when you would make your application
>> run as root, you would also be then granting root level access to all
>> libraries and frameworks you are using, which is relatively speaking a
>> HUGE security hole over putting specific bits of functionality in a
>> standalone and limited helper tool.
>>
>> Take the functions that must be performed as root and wrap them in a
>> helper tool, and have your application call this tool, passing the
>> authorization reference along with the command to perform. You'll be
>> happy you did, really, even though it's extra work.
>
> Explained this way it makes a little more sense. I guess Im just
> concerned that I'll have to re authorize the commandline tool for each
> file that needs removal which would be tedious. Anyway. Back to the
> books
> I suppose.
What you can do is use the sample as shown in AuthSample and MoreAuth
which show the process of having a command line tool repair itself...
That way, they have to authorize the first time so the tool can repair
itself, but then (if you like) subsequent attempts do not need new
authorization. I'd suggest also possibly setting up a custom right or
rights for the operations you want to perform, and then you can change
the timeout value to be whatever you want (including unlimited) so that
once they authorize once upon application startup, they don't need to
do it again until they quit the program. There are lots of options, I
think it's quite flexible. Check out the AuthSample and MoreAuth
examples over at Apple's site.
Steve






Cocoa mail archive

