On Oct 2, 2008, at 8:20 PM, Jason Coco wrote:
On Oct 2, 2008, at 21:20 , Bill Bumgarner wrote:On Oct 2, 2008, at 12:30 PM, Kelly Graus wrote:Is the only way to allow a user to write to a protected location use the AuthorizationExecuteWithPrivileges function? If so, is there a way to tell when the application has quit, and get the exit code? If not, how would I go about getting sufficient privileges to write to protected locations? Does using a setuid tool mess up the ability for a user to delete an application, assuming the setuid tool is imbedded in an application's bundle?Thanks for any help!See Nick's response... it was helpful. However -- I have a question:What are you trying to do and what do you hope to gain by protecting the data in this fashion?Specifically, going down this path means that any non-admin user will not be able to use whatever functionality in your application requires authorization.... is that intended?If you do need administrators to write to privileged areas sometimes, you should look at the /sbin/libexec/authopen tool which is designed for that.However, I believe the default for both those directories is admin +w anyway.
Which will still leave non-admin users out of luck in using the OP's application.
The user account I use all the time is a non-admin account. Primary use admin accounts open up a series of security holes that are easily avoided.
Does using a setuid tool mess up the ability for a user to delete an application, assuming the setuid tool is imbedded in an application's bundle?
If the tool is setuid root, then -- yes -- the user won't be able to deleted the application without administrative rights.
But... don't do that. A setuid root tool is even worse than going through AuthorizationExecuteWithPrivileges(). It is huge security hole in that any user with read access can cause a process to run as root, thus eliminating the authentication hurdle of AuthorizationExecuteWithPrivileges().
So... again... why does the OP's app need to write anything with authorization privileges (and where)?
b.bum
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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 [EMAIL PROTECTED]
