Thread

1. mikestew · 1790117337 · focus · HN ↗

   Here’s my problem with reviving FoxPro in any form: there’s a huge security hole in the Database Container (DBC) design. For DBCs to be useful, they must be read/write to all users (there is no permissions scheme). DBCs have stored procedures that can run any FoxPro code, including Win32 calls made from the FoxPro runtime. The stored procedures are stored as plain text in a “memo” field. Do you see where this is going? With a little technical knowledge, one can modify that INSERT trigger to whatever you like. EDIT: as the DB is just files in the file system, modifications can be made using a text editor, bypassing any checks in the FoxPro runtime. FoxPro just executes what it finds in there.

   My recommendation is to get rid of the DBF/DBC files and move to a SQL DB of some flavor ASAP. If you have the source code, use ODBC or OLE DB to point to a server.

   Source: filed that bug over 20 years ago when I worked on the Fox team. No, it wasn’t going to get fixed without rewriting large parts of how the DB engine worked.

   1. mamcx · 1790131244 · focus · HN ↗

      > Here’s my problem with reviving FoxPro in any form

      And then it moves to the orthogonal problem:

      > SQL DB

      (that in fact means: An app made for end users that are not trusted by default but really are somehow that is a improper implementation of the relational model and more improper developer platform, more like wordpress, and because is mostly deployed "networked" suddenly need to worry about remote access, that is totally not the main point of old Fox/dbase apps!)

      And the funny things: SQL injection is not a problem with a Fox app (use of a stringy api is a MAJOR issue that lack of a permission model)

      ---

      As one that have long experience with FoxPro and try to revive the style, lets go to the core of the problem:

      Imagine you say to a C developer:

      "You can't use `fopen` and other filesystem APIs, because well you have access to to the whole filesystem"

      Or even better, the user!:

      "You should not own your own filesystem!"

      The DB is like the filesystem, but not that dumb!

      The permissions model is orthogonal. Maybe you (normal) filesystem is running on a networked deployment with access by spies with and other personal that should have top-notch security.

      Or is just a embedded device.

      WHAT DECIDE THE SECURITY MODEl?

      The kind of storage?

      Nope!

      Is the deployment and use case.

      Similarly, what decide the security of a database?, the fact is a "database"?

      No!, that is ridiculous. If you need to layer some kind of access control or whatever, is outside of the kind of storage you choses.

      In fact, see how Wonderfully could be all if the "filesystem" where an actual database and you can run relational queries on top: Millions of "cli utilities" suddenly are unnecessary, the user (and developers!) have more freedom and control, and your big corp with byzantine rules will be even more happy.

      ----

      P.D: I'm very well aware of the limitations of Fox, is ancient software! but the style of programming? Is like have a taste of start trek

      P.D.2: And note that the vector attack described here is a fault of the dumb filesystem, actually!

Unofficial Hacker News client; not affiliated with Y Combinator.