Finding out executable location from a c program

[Alastair Houghton]

On 5 Dec 2007, at 08:23, Antti Karanta wrote:

>>> Furthermore, even if you do find the path somehow, a malicious (or
>> just misguided) user could move things around between the time you
>> obtain the path and the time your code is actually running.
>
> Doesn't this scenario equally apply to the situation where you place
> the files you need in a "known location"?

No.  Because the usual known locations are all protected by their  
default security settings.  The user in question would need access to  
those locations and if they had that then in many cases they don't  
need to use these kinds of tricks.

The risk with finding the executable path is that it's much more  
likely that your code can be tricked somehow into thinking the  
executable is somewhere other than where it really is.  Even if you're  
using realpath(), I can hard link from somewhere that I can write to  
to your executable file, and then I can substitute whatever files I  
like for your usual resources.  If your program has any security  
privileges whatsoever, that makes for a nice security hole.

>> And if you want to package-up pre-built versions of your launcher  
>> with
>> Groovy itself, you can do that too, using the various system-specific
>> packaging tools (e.g. PackageMaker on OS X).  Certainly on OS X, many
>> users would prefer to be able to double-click a "Groovy.pkg" file
>> anyway.  The same is true, I think, for other systems.
>
> You are absolutely right.
>
>> If you do that, you can delete all the grotty code to find the
>> executable path on all the systems you currently support, *and* the
>> program will be more likely to run without modification on other
>> systems too.
>
> Ok, I see your point - when in Rome, do as the Romans do. = )

:-)  Yeah, sort of.  I think my point was really that *not* trying to  
find the executable path was an easier, safer and more portable  
solution, and that there aren't really any disadvantages worth  
mentioning (for your specific application, where it's actually IMO  
beneficial if its installed in a well-known place).

> BTW, if I made a bundle, the code I have would be exactly the same (as
> I'm using the bundle API to find the exec location). Why would finding
> the necessary files by the executable location be any more justified  
> in
> that case? I.e. is the existence of this part of the bundle API a
> mistake?

Bundles are there to solve the kind of problem you're trying to solve,  
certainly; the benefit is that they don't rely on the executable  
location (or, when they do, it's system code doing so, not your code,  
so its less likely to contain bugs or security holes and when such  
things do get found and fixes your app will take advantage of that  
automatically without you having to release a new version).  Of  
course, they're really only applicable on Mac OS X and NeXT (and maybe  
a few other esoteric systems---e.g. Acorn RiscOS used to do something  
similar).

So bundles are certainly a good solution for developers writing  
software specifically for use on Mac OS X.  Sometimes they're a good  
way to go for ported software as well (e.g. having things bundled as a  
framework rather than installing in /usr/local/include and /usr/local/ 
lib), and you could certainly use a bundle if you wanted, it's just  
that on Mac OS X, the usual Unix-like approach will work nicely  
already (for what you're doing) and if you make it into a bundle on  
the Mac and then don't put in a load of symlinks in the appropriate  
places it just makes it incompatible with the same package installed  
on e.g. Linux.

Kind regards,

Alastair.

--
http://alastairs-place.net