* Before setting /sim/aircraft-dir from the --aircraft-dir option,
canonicalize its value with SGPath::realpath() as is already done in
FGGlobals::append_aircraft_path() for the paths given with --fg-aircraft
or via the FG_AIRCRAFT environment variable.
* This fixes a bug when --aircraft-dir is used, due to the fact that
fgValidatePath() canonicalizes its 'path' argument before matching it
against the allowed patterns, and therefore will not validate paths
under the directory specified with --aircraft-dir if this directory has
been given in a non-canonical form by the user (e.g., containing at
least one symlink component).
* This fix does not lower security: the path which is canonicalized has
been explicitely given by the user. This operation is already done for
all paths specified with --fg-aircraft or via the FG_AIRCRAFT
environment variable, via Options::initPaths() which calls
FGGlobals::append_aircraft_paths().
* To reproduce the bug, create a symlink (e.g., /tmp/aircrafts) to a
directory suitable for --fg-aircraft, then run:
fgfs ... --fg-aircraft=/tmp/aircrafts \
--aircraft-dir=/tmp/aircrafts/SenecaII --aircraft=SenecaII
This will trigger many failures such as:
loadxml: reading '/tmp/aircrafts/SenecaII/Dialogs/registration.xml'
denied (unauthorized directory - authorization no longer follows
symlinks; to authorize reading additional directories, add them to
--fg-aircraft)
(from do_load_xml_to_proptree() in flightgear/src/Main/fg_commands.cxx)
I have also tested this with the ec130b4 and the 777-200ER. Same
problem, same fix.
* If one has the same aircraft in several aircraft directories,
FlightGear should not mix resources from the various aircraft
directories. For instance, if one starts FG with:
--fg-aircraft=/my/personal/dir:/path/to/fgaddon/Aircraft
and one has in /my/personal/dir/ec130 a clone of the upstream
developer repo, FlightGear should use either the upstream version from
/my/personal/dir/ec130 or the FGAddon version from
/path/to/fgaddon/Aircraft/ec130, but not some strange, untested hybrid
of both.
* This commit makes sure that when the looked-up resource starts with
Aircraft/<ac>, where <ac> is the current aircraft name [last component
of aircraftDir = fgGetString("/sim/aircraft-dir")], then
AircraftResourceProvider::resolve() doesn't search other aircraft
directories if the resource isn't found under 'aircraftDir'.
* To reproduce the bug before this commit, you may add the following
code (there is nothing specific about the SenecaII here, it's just the
aircraft I used for testing):
var file_path = resolvepath("Aircraft/SenecaII/flo-test");
if (file_path != "")
gui.popupTip("flo-test found", 2);
else
gui.popupTip("flo-test not found", 2);
in a keyboard binding for the SenecaII (for instance; you may use the
F11 binding that otherwise only prints a short message). You should
add this to the SenecaII/SenecaII-base.xml file *that will be loaded
by FlightGear*, let's say the one under /my/personal/dir in the
example above (beware of the <path-cache> in autosave_X_Y.xml). Then,
by creating or removing a file named "flo-test" in the SenecaII
subdirectory of other aircraft dirs (for instance,
/path/to/fgaddon/Aircraft in the example above), you can see that the
behavior of the loaded aircraft is influenced by the contents of
unrelated versions of the same aircraft that might be present in other
aircraft dirs (e.g., loaded /my/personal/dir/SenecaII influenced by
/path/to/fgaddon/Aircraft/SenecaII).
* Aircrafts loading resources using paths relative to the current
aircraft directory (e.g., with 'resolvepath("flo-test")') are not
affected by this kind of problem, because this scheme is handled by
CurrentAircraftDirProvider, which does not exhibit this bug.
Kévin Seroux:
As reported here (http://forum.flightgear.org/viewtopic.php?f=32&t=26629),
the FGCom standalone client use 100% of the CPU when it is in OBS mode. The fact to add the shortest sleep time
(1ms) has solved the problem. With this patch, I run FGCom with 1% of CPU usage instead of 100%.
negative latitude/longitude coordinates resulted in negative WEST/
SOUTH coordinates for the default format 0 (zero).
This should be now fixed so that
+12.3 gets formatted as 12.3N/E
-12.3 gets formatted as 12.3S/W
https://bugs.debian.org/780867
This messy approach is to minimise changes during freeze; for 3.7,
I plan to make realpath() handle non-existent files as "realpath
they would have if created now" and get rid of fgNormalizePath
This is insecure because it always (not just on Windows) converts
\ to / before .. checking. Either use the path it returns (as in
f_open()) or use an SGPath (where this conversion is already done)
Only a minor problem because the affected functions are limited to
the .sav file type
and using speed up time to allow a fine displayed predicted position
when time accelerated (no more jumping planes accelerated using the mp patch)
tell me if it's not the good pace to do such things ;)
