Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G


From FlightGear wiki
Jump to: navigation, search
This article has been nominated for deletion. To discuss it, please visit the talk page.

Do not remove this tag until the discussion is closed.

Reason for the nomination: This article has been completely obsoleted by FGData commit 45c3eeb9ad120accd003f56ab598aa11bf070878.

IOrules is a file that defines which file paths can be opened for reading and/or writing by Nasal. This file can be found in $FG_ROOT/Nasal/IOrules or, if available, $FG_HOME/Nasal/IOrules.

Powers of writing to disk

FlightGear is a local program, and software it loads from the local drive can certainly do local I/O if it wants without breaking typical security models. That's the whole idea behind being able to download software from the internet in the first place.

The power of a system isn't defined by what is used, but by what can be done, and allowing Nasal scripts to write to the disk is a powerful feature. Dangerous if uncontrolled. But at the moment write access should only be possible to $FG_HOME/Export/, so I don't really see the problem. And if we offer the feature, people will find innovative ways to use it. If we don't, they won't. Potential use cases would be:

  • Writing non-<PropertyList> XML files, like they are used in the traffic manager and for flight plans.
  • Writing *.stg files (adding models or adjusting elevations for the current terrain).
  • Writing an *.svg file with a graphic showing the flight path, or flight parameters. Or a smilie.
  • Writing or modifying a PostScript file, for example to hand out to children on LinuxTag or flight shows, with flight time and duration automatically filled in. You could move that straight to the printer. (Caution: an attacker could empty your toner cartridge with that! ;-)
  • Writing a TeX file with a table showing flight parameters,fuel consumption, whatever.

None of this crucial, and all of it doable with external scripts from XML exported data. But the possibility to do it with Nasal drivers from within is nice. And something that other flight sims might not be able to do. Maybe something that our corporate users would like to do.

Not that we should have waited much longer for some security enhancements in any case, but the fact that there seem now to be web sites with random fgfs addons to download made me feel a bit uncomfortable. It was all too easy to cause quite some damage, and not everyone reviews the fgfs stuff he installs. Of course, it would be better to keep the official repositories as the central place for all sorts of scenery and aircraft addons, and not to rely on any outside source. And to review the stuff before committing.

Any script that could write to the disk however is a potential security threat since not everybody (or probably no one) would check every file of a downloaded aircraft for security problems

Limiting IO operations

Multiplayer security considerations

The historical fear has been the interaction with the MP environment: the MP code can write to the property tree, and arbitrary property nodes have on various occasions be hooked to execute Nasal code. Being able to execute arbitrary Nasal code on another machine over the network would be a security disaster if that code could do I/O or spawn programs, etc...

Ideally, I guess I'd prefer a sandbox on the other side: an architecture that expressly prevents network data from being executed somehow, probably by strictly limiting the areas in the property tree it can write to. But this kind of architecture can work too: it just requires that every "potentially unsafe" operation be sandboxed in the same way as I/O.

Nasal IO and IOrules

It's well known that Nasal has an io module with wrappers around fopen(), fclose(), etc. So this feature is for Nasal's io.open() only, and handled in Nasal to 100%.


The first change is to fg_init.cxx. It makes sure that crackers can't use XML code like the following to sneak in a bad home directory path, which, thanks to the write="n", fgfs wouldn't have been able to overwrite:

      <fg-home write="n">.</fg-home>

/sim/fg-home should now be safe until the security code has read it. You can now override it with environment variable FG_HOME, but no add-ons can do that via XML or Nasal.


The second change is in $FG_ROOT/Nasal/io.nas. It replaces the original io.open() with a version that checks for illegal write access to non-authorized directories. (Reading is allowed everywhere. Use the OS' permissions to prevent that.) The list of allowed directories is hard coded in io.nas:

The rules are now read from $FG_ROOT/Nasal/IOrules or, if available, $FG_HOME/Nasal/IOrules. That way people who don't have write permission for $FG_ROOT/Nasal/io.nas can still extend and modify the rules. The default is:


This can be overridden with a file $FG_HOME/Nasal/IOrules that is either empty, or contains these rules:


It can be overridden with any rules. The important point is that a local file doesn't add to the global rules, but replace them. And an empty file or one with "READ DENY *\nWRITE DENY *" is the most restrictive you can have.

Note, however, that file access via fgcommand() isn't affected by the rules at all. There's only an ".xml" extension enforced by, and it will abort if the file isn't a <PropertyList>. This should be safe enough.

IOrules is there for a reason, and it should not be "beaten". If it is possible to beat IOrules that is a bug that needs to be squashed.

Default paths in IOrules

By default you may write to any file named $FG_HOME/*.sav, $FG_HOME/*.log or $FG_HOME/Export/* There are more, but these seem the most logical file names for a Nasal script. By default, you can only write files with certain extensions to /tmp and $FG_HOME and nothing at all to $FG_ROOT. FlightGear's internal access rules for Nasal scripts are defined in $FG_ROOT/Nasal/IOrules but of course the file system permissions must also permit the action you want to do. FlightGear's access validation mechanism is different from any OS-level access restrictions, and implemented in a cross-platform fashion.

External links