Nasal (in SimGear) already had support for file I/O since the last Nasal update, but the line that would have activated it was commented out until yesterday. The now available Nasal "io" module allows some interesting stuff, such as direct appending of OBJECT entries to *.stg files from nasal code. But it's also potentially dangerous. What do we have to do to limit unwanted side effects, or rather: intentional malicious use of it?
With Nasal io every aircraft from external sources can run Nasal code that reads local files and sends them over the net. Of course, every script, every Makefile, etc. can do that, too. But one wouldn't necessarily expect that from an fgfs aircraft. The operating system isn't really in any danger. It protects itself by means of file permissions/ACLs. Sending arbitrary stuff over the net could be done via voice interface. But here the host/port are set in $FG_ROOT/preferences.xml to localhost:1314, and the property is write protected. It's read before any nasal code runs, and later removing of the node's write protection and changing the values via Nasal doesn't have any effect. So, until now this should have been safe. But now Nasal code can change the values right in preferences.xml. Would we have to disallow writing to $FG_ROOT/preferences.xml? Other systems might be able to send arbitrary data, too, such as the MP/chat. Host/port are settable via command line, but also via properties, and that could be changed via aircraft *-set.xml file already (not tested). Sending data over net isn't the only problem. Some Nasal fun code could easily wipe the user's $HOME, or overwrite ~/.bashrc or other files that are executed automatically at login. What can, what shall we do with those? Of course, one could add a command line option that enables/disables the io lib, and make it off by default. But once it's on, it can enable itself, e.g. by writing to ~/.fgfsrc, or to fgrun's config, or any fgfs wrapper it finds in ~/bin/. :-) Should we do more, at all, than only auditing all Nasal contributions to CVS, and warning of aircraft or other fgfs data files with potential Nasal contents from outside & untrusted sources? I think we can overview the files in CVS by means of fg-check (or similar), and good old code review. Or should we limit all file access (read and write) to files under subdirectories of $FG_ROOT and/or ~/.fgfs/? People could still add links there to other directories. If so, how would we do that, without having to modify the files in simgear/nasal/, avoiding a Nasal fork, which would make updates from the Nasal repository harder. We'd need to make sure that all paths start with $FG_ROOT/*/ or $FG_HOME/*/ and contain no "..". I assume the nasal code would have to add a path validation callback method, or something!? m. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
