Re: Subclassing NSUserDefaultsController
Re: Subclassing NSUserDefaultsController
- Subject: Re: Subclassing NSUserDefaultsController
- From: James Bucanek <email@hidden>
- Date: Sun, 20 Sep 2009 08:44:30 -0700
Thomas Bauer <mailto:email@hidden> wrote (Sunday,
September 20, 2009 2:39 AM +1200):
In some cases my application needs to modify and get the user defaults from a
different user than the one it is launched under. Since this affects not only
things done programmatically, but also parts of the user interface that use
bindings, I was thinking an elegant solution would be to make the
SharedDefaults controller be a subclass and override the designated init
method to either be initialized by sharedDefaults or a NSDefaults object
created with initWithUser. Unfortunately this does not seem to work on a basic
level.
At that basic level, this should never work. Your user (UID)
should never, under normal circumstances, have access to any
non-public files belonging to another user, especially not their
~/Library folder. So even if you could coerce NSUserDefaults or
CFPerferences to access the file, the basic security model of
Mac OS X / BSD would prevent them from reading or changing it.
The straightforward solution is to create a SetUID helper or
daemon process that you can launch and will run as that other
user. It could be an SUID->root process that dynamically changes
its EUID to the user you need to affect, or be a pre-configured
SUID->user (probably the easiest solution) that always runs as
that particular user. Your process could launch the helper then
communicate what changes you need to make via inter-process messaging.
--
James Bucanek
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden