RE: Finding out executable location from a c program

  • > -----Original Message-----
    > From: Alastair Houghton [mailto:<alastair...>]
    >
    > On 23 Nov 2007, at 20:52, Antti Karanta wrote:
    >
    >> On Tue, 20 Nov 2007 14:36:53 +0200, Alastair Houghton
    > <alastair...>
    >>> wrote:
    >>
    >>> It's perhaps worth saying though that using the path of your tool
    >>> is generally an evil thing to do.
    >>
    >> Why is it evil?
    >
    > Because you can't guarantee that you can get the path, in general.
    > You have to use system-specific hacks to obtain it,

      System specific, yes, but "hack" is a pretty strong word here as (at
    least on the four os:es I'm currently targeting) there is a well defined
    and documented way to get the said path.

    > Even on systems that do let you obtain such a path, you may
    > find that the path is that of a symlink

      Not a problem, I just call "realpath" function.

    > 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"?

    > For the type of application you're talking about, hard-coded paths
    > seem the most sensible choice, possibly allowing GROOVY_HOME to
    > override them if it's set.  You can easily find the paths to use when
    > your users build your program (it looks like the type that's built
    > from source, right?)

      Most people would not build the main groovy distribution themselves.
    ATM people who want to use the native launcher have to build that
    themselves (except on windows). So the answer is yes(ish), at least for
    now.

    > 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. = )

      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?

          -Antti-
  • 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
previous month december 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Go to today