Re: getcwd acts different in xcode/finder
Re: getcwd acts different in xcode/finder
- Subject: Re: getcwd acts different in xcode/finder
- From: Alastair Houghton <email@hidden>
- Date: Mon, 8 Dec 2003 19:28:50 +0000
> On Saturday, December 6, 2003, at 02:04 PM, Brian Barnes wrote:
>
>> I don't know if this happened because of xcode or 10.3; but that's
>> when it changed for me.
>>
>> I'm building an application into a pre-build bundle in the directory
>> /users/bbarnes/dim3. When running under XCode, getcwd returns
>> "/users/bbarnes/dim3". When running from the finder, it returns "/"!
On 8 Dec 2003, at 18:44, Thomas Dibble wrote:
> Correct, the Finder (Puma, Jaguar, AND Panther) always starts
> processes in root (/), which is different from Windows certainly
> (which starts apps in their executable directories by default I
> believe) but not too different from several other *nix's (KDE and
> Gnome, I believe, default to starting with a / working folder). You
> should be able to change the debugger/run settings in the IDE to mimic
> this behavior (just set the starting directory to / instead of the
> output or project folders). Programatically, think of the GUI as
> always sitting in the root directory and starting your app by
> executing /Applications/MyApp.app/Contents/MacOS/MyApp.
>
> Generally, if you rely on your app's location on hard disk I believe
> you should get that info from argv[0] or the related Mac OS system
> calls, not from getcwd.
You shouldn't use argv[0] either, because it is set by your parent
process, which is free to set it to whatever it wants (check out the
man page for exec()... you'll notice that the system doesn't use
argv[0] to locate the executable file to run). The CFBundle and
NSBundle APIs are the best way to get this information, followed by the
dyld APIs. Using argv[0] for anything other than display purposes is a
very bad idea IMHO, and in some circumstances is actually a major
security hole... to give a couple of examples:
1. Imagine you have a setuid program that needs to execute itself for
some reason. If it uses argv[0] to obtain its own path, then I can get
it to run *any* executable on the system with elevated privileges by
calling
execl("<path to program>", "/Users/alastair/maliciousprogram", ...);
2. The security server's Authorization dialog currently displays
argv[0] for the program that requested authorization, so a malicious
program can easily pretend to be another program... e.g. I could write
a program that waits for the user to execute Disk Utility, then
displays an authorization dialog claiming to be Disk Utility, allowing
me to obtain rights to do whatever I please without alerting even a
fairly suspicious user to the presence of my program. (Of course, I
don't have to wait for them to run Disk Utility, I could equally just
claim to be "System" or something a typical user would believe.) See
rdar://3486235
There are other possible security holes that you can create if you
aren't careful with the contents of your argv[] array... don't forget,
the process that exec()'d your program might be malicious (or might be
under the control of a malicious user). The same goes for the argv[]
information obtained from sysctl().
Kind regards,
Alastair.
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.