On 23 Jan 2009, at 05:05, Michael Ash wrote:
On Thu, Jan 22, 2009 at 10:15 PM, Joe Turner <joetur...@me.com> wrote:
On Jan 22, 2009, at 4:57 PM, Nick Zitzmann wrote:
On Jan 22, 2009, at 4:09 PM, Joe Turner wrote:
I see. Then, how would you suggest to create a cloner/deleter, if
it
needs root privileges, but cannot use the security framework?
I didn't say you couldn't use the security framework. I said you
ought to
consider re-thinking your strategy.
And, since running scripts from root is dangerous, then is there
any good
way to be able to delete protected (not your user account) files?
Or, should
I just have it copy or delete files the user has access to?
There's nothing wrong with running scripts strictly as root, since
a lot
of system scripts are run this way. But AEWP() doesn't run
executables as
root; it runs them as the user with root privileges. There's an
important
difference.
Instead of running a shell script, run another non-GUI command
line tool
of your making with AEWP() that does the required privileged
task(s).
Running shell code with root privileges as some user is possible,
but it's
an easy attack vector due to the inheritance of the user's shell
environment. Running a command line tool is a bit more difficult
to hack
(but still possible if someone is determined enough). Plus, then
you can use
NSFileManager. :)
You could even take security to the extreme, as I once did in an
application, and check signatures before calling AEWP(), but
that's probably
too extreme, as it's unlikely someone will rewrite or replace your
executable unless the file system gave them permission to do so.
Okay, I guess I should just put scheduling without needing the
password to
the back of my queue.
I have one more question (sorry for all of these questions): If I
call
AuthorizationCopyRights() every 280 (or anything less than 300
secs) during
the clone, will it keep the authorization alive (no need to enter
password
again)?
Don't do that. The standard way to accomplish a permanent unlock that
you're talking about is (I think) to have a suid root tool. You use
AEWP to run it as root so that it can become suid root, and after that
it simply *stays* suid root, as that's a filesystem property that
won't be disappearing spontaneously. As long as it's suid root you
don't need to touch AEWP again.
Of course you need to securely control access to your suid root tool
in that case, and I don't recall exactly how you do this, but I
believe the authorization APIs allow you to generate tokens that you
can pass to the tool to be checked for validity so that not just
anyone can come in and use the tool. And I'm pretty sure that Apple
has sample code to illustrate this. Definitely look at that sample
code no matter what; these APIs are ridiculously difficult to get
right, and you don't want to be working with them without a concrete
example sitting in front of you that you can crib from.
Another source of info on this would be Dalrymple + Hillegass -
Advanced Mac OS X Programming.
It doesn't seem to be searchable on the web so you will need the
physical papery object.
Chapter 17 covers the whole SUID/ticket business in detail (21 pages )
with a working example.
Mike
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/jonathan%40mugginsoft.com
This email sent to jonat...@mugginsoft.com
Jonathan Mitchell
Central Conscious Unit
http://www.mugginsoft.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
