• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Preventing the writing of the NSUserDefaults
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Preventing the writing of the NSUserDefaults


  • Subject: Re: Preventing the writing of the NSUserDefaults
  • From: Eric Peyton <email@hidden>
  • Date: Sun, 24 Mar 2002 12:27:53 -0600

On Sunday, March 24, 2002, at 12:09 PM, Gerben Wierda wrote:

On Sunday, March 24, 2002, at 04:33 , Eric Peyton wrote:

What do you want to do instead? Write them someplace else?

NSUserDefaults is just a convenience, you can create your own defaults in whatever manner you choose (use a Dictionary to store them and write them out use NSDictionaries writeToFile: method, etc.), however, I don't believe you will be able to easily extend or change NSUserDefaults without dropping down to the CFPreferences level ...


No. the problem is that the app under certain circumstances is launched by AuthorizationExecuteWithPrivileges(), in other words, it runs with a different effective uid (root) than the real uid.

Actually - won't an app run with AEWP run as euid root and uid root?

The NSUserDefaults file is then written with owner root and mode 600, but in the user's ~/Library/Preferences. This is bad, if the app also is run non-setuid sometimes.


Yes, standard setuid root executables have the same issues.

I either need to make sure I control completely the writing of ~/Library/Preferences/appid.plist, or when the app finishes, but after it has written the defaults database, I need to change ownership of that file.


You should control the writing of the files yourself in this situation (I think).

The alternative is to make sure the app runs with real uid root as well (setuid(geteuid())), but that means it will not use the user's settings for how it looks (blue, graphite, etc).

So, I do not need to do preferences, but I need to know what part of Cocoa triggers preferences storage and how.

I know some part of Cocoa send 'synchronize' message to the user defaults once in a while. Who? When? Can I set a delegate for a NSUserDefaults object and catch that method? Or is there a notification I can catch in my Application delegate? Or can I subclass NSUserDefaults and then somehow replace the NSUserDefaults sharedInstance?


I would suggest putting a category on NSUserDefaults and overwriting "synchronize". This would allow you to make sure that nowhere in the app is the writing triggered.

Then I would keep my own dictionary of the defaults and then write them out into the correct place (~loggedInUser/Library/Preferences). You can get the uid of the logged in user from the system configuration framework.

Eric

G
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Preventing the writing of the NSUserDefaults (From: Gerben Wierda <email@hidden>)

  • Prev by Date: Re: 8-bit chars in @""
  • Next by Date: Re: string coloring
  • Previous by thread: Re: Preventing the writing of the NSUserDefaults
  • Next by thread: Need advice on OpenGLView behaving like a control
  • Index(es):
    • Date
    • Thread