On 24/04/2008, at 4:35 AM, Michael Watson wrote:
Yes, it's a helper tool. It runs for a couple of seconds (under normal conditions) and exits immediately. It interacts with the file system by reading information about some directories, so its launched duration is, of course, bound to the responsiveness of the hard drive on which it's operating. As such, "a couple of seconds" might be "five or ten seconds" on machines where the drive is spinning up, otherwise busy, etc. It's certainly possible that someone might invoke fast user switching right in the middle of the tool running, but it's /probably/ not an issue. I'm still not quite convinced it isn't, just yet. I need to do more thinking about it. The discussion so far has been very helpful.As far as connecting to the window server goes, Apple states:http://developer.apple.com/technotes/tn2005/ tn2083.html#SECWINDOWSERVER"Apple plans to disable the global window server service in a future release of Mac OS X. Do not write any new code that uses the global window server service."So when you say "default window server", are you speaking of the global window server, or the default window server associated with the current console session?
The document you are looking at is talking about unsafe frameworks for daemons. You're writing a helper tool, not a daemon, so it's not applicable.
A helper tool (that's run as a helper to a GUI application) will run fine linked to any frameworks. If the helper tool is spawned by a GUI process, it will inherit its session and so there's no issue with it using the global window server service. The only issue is what security hazards linking to other frameworks introduce. The idea is that you should link to as little as possible so as to minimise the risk and you should probably avoid using Objective-C (although I don't actually know if there are any security risks from using Objective-C— non privileged Input Managers are surely not loaded). I would have thought that any security risks that exist from linking to other frameworks are considered bugs which means that there won't be a list of “safe” frameworks anywhere and if you find any issues, they need to be reported to Apple.
Kind regards, Chris
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]
