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. boredjohnny · 1790118595 · focus · HN ↗

      Thanks, this is the most useful comment here. FoxDev reads the DBC the same way VFP does, so today it inherits the hole exactly. The runtime is actually the one place it can be fixed. I would put in a hash of the stored procedure text into the built executable and refuse to run a container whose procs don't match. Adding it to the list. Would you mind if I quoted your comment in the issue?

      1. mikestew · 1790122457 · focus · HN ↗

         Feel free to quote me, contact info in profile if needed.

         EDIT: sorry, I originally just skimmed your comment. I was unclear in my original comment: the files can be accessed and “hacked” from the file system with a text editor. (And a bunch of deleted stuff because I misread your comment.)

      2. [deleted] · 1790123812 · focus · HN ↗

         [deleted]

Unofficial Hacker News client; not affiliated with Y Combinator.