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. 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
